This is a guide on how to setup OpenFaaS — Serverless Functions Made Simple on Kubernetes 1.8 or later with minikube. minikube is a Kubernetes distribution which lets you run a Kubernetes cluster on your laptop — it’s available for Mac and Linux, but is most commonly used with MacOS.
OpenFaaS in 2021:
Quite a lot has changed since this blog post was written. KinD, Multipass and K3d all provide light-weight alternatives to local Kubernetes. Minikube is no longer the only option.
Please try one of the following:
Getting set up with Minikube on MacOS
brew is a package manager for MacOS, you can use it to make installing packages quicker and easier. https://brew.sh
- Install minikube if you don’t already have it on your system.
- Install the xhyve driver or VirtualBox which will be used to create a Linux VM for minikube. I find the VirtualBox option to be the most reliable.
- Setup minikube using the official docs — make sure that you enable RBAC, too.
curl -sL cli.openfaas.com | sudo shor
- Install the
helmCLI via brew:
brew install kubernetes-helm
- Start a local cluster:
Docker Captain’s tip: get a more native experience with your Kubernetes development by using Docker for Mac and Kubernetes, read my first impressions here.
Deploy OpenFaaS to minikube
- Create namespaces for OpenFaaS core components and OpenFaaS Functions:
kubectl apply -f https://raw.githubusercontent.com/openfaas/faas-netes/master/namespaces.yml
- Add the OpenFaaS helm repository:
helm repo add openfaas https://openfaas.github.io/faas-netes/
- Update all the charts for helm:
helm repo update
- Generate a random password:
export PASSWORD=$(head -c 12 /dev/urandom | shasum| cut -d' ' -f1)
- You may want to take a note of your password with
echo $PASSWORDbefore continuing.
- Create a secret for the password
kubectl -n openfaas create secret generic basic-auth --from-literal=basic-auth-user=admin --from-literal=basic-auth-password="$PASSWORD"
- Install OpenFaaS using the chart:
helm upgrade openfaas --install openfaas/openfaas --namespace openfaas --set functionNamespace=openfaas-fn --set basic_auth=true
- Set the
export OPENFAAS_URL=$(minikube ip):31112
- Finally once all the Pods are started you can login using the CLI:
echo -n $PASSWORD | faas-cli login -g http://$OPENFAAS_URL -u admin — password-stdin
You’ll now see the OpenFaaS pods being installed on your minikube cluster. Type in
kubectl get pods -n openfaas to see them:
NAME READY STATUS RESTARTS AGEalertmanager-6dbdcddfc4-fjmrf 1/1 Running 0 1mfaas-netesd-7b5b7d9d4-h9ftx 1/1 Running 0 1mgateway-965d6676d-7xcv9 1/1 Running 0 1mprometheus-64f9844488-t2mvn 1/1 Running 0 1m
If you run into any issues you can follow the troubleshooting guide for Kubernetes with OpenFaaS or the helm installation guide.
The API Gateway contains a minimal UI for testing functions and exposes a RESTful API for function management. The faas-netesd daemon is a Kubernetes controller which connects to the Kubernetes API server to manage Services, Deployments and Secrets.
Prometheus and AlertManager work in tandem to enable auto-scaling of functions to match demand. Prometheus metrics give you operational oversight and allow you to build powerful dashboards.
Prometheus dashboard example:
To get your own Grafana dashboard, see the OpenFaaS workshop at the end of the post.
OpenFaaS uses the Docker image format for the creation and versioning of functions which means that unlike many other FaaS projects you can use this in production to do:
- vulnerability scanning
- rolling upgrades
You can also deploy OpenFaaS to your existing production cluster and make use of spare capacity. The core services require around 10–30MB of RAM each.
A key advantage of OpenFaaS is that it works with the container orchestration platform’s API, which means we integrate natively with both Kubernetes and Docker Swarm. Also, since our functions are properly versioned within a Docker registry, we can scale our functions on demand without any additional latency associated with frameworks that build functions on demand.
Scaffold a new function
faas-cli new --lang python3 hello
This will create
hello.yml along with a
handler folder containing your handler.py file and requirements.txt for any pip modules you may need. You can edit these at any time without worrying about maintaining a Dockerfile — we do that and use best practices:
- multi-stage builds
- non-root users
- Official Docker Alpine Linux builds for the base (this is swappable)
Build your function
Your function will be built on your local machine and then pushed to a Docker registry. Let’s use the Docker Hub — just edit the
hello.yml file and enter your user account name:
provider: name: faas gateway: http://127.0.0.1:8080functions: hello: lang: python3 handler: ./hello image: alexellis2/hello
Now invoke a build. You will need Docker on your local system.
faas-cli build -f hello.yml
Push the versioned Docker image which contains your function up to the Docker Hub. If you’ve not logged into the Docker hub then type in
docker login before carrying on.
faas-cli push -f hello.yml
Once you have multiple functions you can use the
--parallel=N flag to build or push with multiple cores at once. The CLI also supports options such as
To save on typing you can also run
faas-cli upwhich combines the
deploysteps in one single command.
Deploy and test your function
Now you can deploy your function, see it listed and invoke it. Each time you invoke the function we collect metrics which are made available through Prometheus.
$ export gw=http://$(minikube ip):31112$ faas-cli deploy -f hello.yml --gateway $gw
Deploying: hello.No existing function to removeDeployed.URL: http://192.168.99.100:31112/function/hello
You are given a standard route for invoking the function in the deployment message, but can also use the CLI to save on typing:
$ echo test | faas-cli invoke hello --gateway $gw
Now list the functions deployed and you will see the invocation count has gone up.
$ faas-cli list --gateway $gw
Function Invocations Replicashello 1 1
Note: this command also accepts a
--verbose flag for more information.
Since we are running OpenFaaS on a remote cluster (a Linux VM) we set up a
--gateway override environmental variable. This could also be a remote host on a cloud platform. The alternative is to update the gateway value in your .yml file.
Moving beyond minikube
Once you are familiar with OpenFaaS on minikube you can deploy to any Kubernetes cluster running on Linux hosts. Here’s an example of OpenFaaS running on Kubernetes on Google’s GKE platform by Stefan Prodan of WeaveWorks demonstrating the built-in auto-scaling capabilities:
We’ve tested OpenFaaS with many different managed Kubernetes services — you can find instructions in the Kubernetes Deployment Guide.
We have dozens of guides and blog available to get you up and running on the “FaaS Train” — head over to GitHub and bookmark our guides:
I’ve included a short 15min video from Dockercon 2017 in Copenhagen where I gave an overview of Serverless and OpenFaaS at the Moby Summit.
- For all the latest hacks, demos and news follow OpenFaaS on Twitter
- To go deeper with Serverless Functions — try the OpenFaaS Workshop — a dozen self-paced hands-on labs to help you master functions.
- Having problems with Minikube? Try OpenFaaS with KinD — a new lighter-weight alternative that will run anywhere you have Docker.
Written by Alex Ellis, the founder of OpenFaaS.
Thanks to Richard Gee for proof-reading this post.
Join our community Slack and read our weekly Faun topics ⬇
Join a Community of Aspiring Developers.Get must-read articles, learn new technologies for free…
Join thousands of developers and IT experts, get must-read articles, chat with like-minded people, get job offers and…