OpenFaaS - Serverless Functions Made Simple
OpenFaaS (Functions as a Service) is a framework for building serverless functions with Docker and Kubernetes which has first class support for metrics. Any process can be packaged as a function enabling you to consume a range of web events without repetitive boiler-plate coding.
- Ease of use through UI portal and one-click install
- Write functions in any language for Linux or Windows and package in Docker/OCI image format
- Portable - runs on existing hardware or public/private cloud - Kubernetes and Docker Swarm native
- CLI available with YAML format for templating and defining functions
- Auto-scales as demand increases
- Compatible with Istio mTLS (all health checks are done with exec wget)
Note: You must also pass
--set rbac=false if your cluster is not configured with role-based access control. For further information, see here.
Note: If you can not use helm with Tiller, skip below for alternative install instructions.
We recommend creating two namespaces, one for the OpenFaaS core services and one for the functions:
$ kubectl apply -f https://raw.githubusercontent.com/openfaas/faas-netes/master/namespaces.yml
You will now have
openfaas-fn. If you want to change the names or to install into multiple installations then edit
namespaces.yml from the
Add the OpenFaaS
$ helm repo add openfaas https://openfaas.github.io/faas-netes/ "openfaas" has been added to your repositories
Generate secrets so that we can enable basic authentication for the gateway:
# generate a random password PASSWORD=$(head -c 12 /dev/urandom | shasum| cut -d' ' -f1) kubectl -n openfaas create secret generic basic-auth \ --from-literal=basic-auth-user=admin \ --from-literal=basic-auth-password="$PASSWORD"
Now decide how you want to expose the services and edit the
helm upgrade command as required.
- To use NodePorts (default) pass no additional flags
- To use a LoadBalancer add
- To use an IngressController add
Note: even without a LoadBalancer or IngressController you can access your gateway at any time via
Now deploy OpenFaaS from the helm chart repo:
$ helm repo update \ && helm upgrade openfaas --install openfaas/openfaas \ --namespace openfaas \ --set basic_auth=true \ --set functionNamespace=openfaas-fn
The above command will also update your helm repo to pull in any new releases.
Verify the installation
Once all the services are up and running, log into your gateway using the OpenFaaS CLI. This will cache your credentials into your
Fetch your public IP or NodePort via
kubectl get svc -n openfaas gateway-external -o wide and set it as an environmental variable as below:
Now log in:
echo -n $PASSWORD | faas-cli login -g http://$OPENFAAS_URL -u admin --password-stdin
OpenFaaS Operator / CRD controller
If you would like to work with CRDs there is an alternative controller to faas-netes named OpenFaaS Operator which can be swapped in at deployment time. The OpenFaaS Operator is suitable for development and testing and may replace the faas-netes controller in the future. The Operator is compatible with Kubernetes 1.9 or later.
To use it, add the flag:
--set operator.create=true when installing with Helm.
faas-netes vs OpenFaaS Operator
The faas-netes controller is the most tested, stable and supported version of the OpenFaaS integration with Kubernetes. In contrast the OpenFaaS Operator is based upon the codebase and features from
faas-netes, but offers a tighter integration with Kubernetes through CustomResourceDefinitions. This means you can type in
kubectl get functions for instance.
This option is good for those that have issues with installing Tiller, the server/cluster component of helm. Using the
helm CLI, we can pre-render and then apply the templates using
Clone the faas-netes repository
$ git clone https://github.com/openfaas/faas-netes.git
Render the chart to a Kubernetes manifest called
$ helm template faas-netes/chart/openfaas \ --name openfaas \ --namespace openfaas \ --set basic_auth=true \ --set functionNamespace=openfaas-fn > $HOME/openfaas.yaml
You can set the values and overrides just as you would in the install/upgrade commands above.
Install the components using
$ kubectl apply -f faas-netes/namespaces.yml $ kubectl apply -f $HOME/openfaas.yaml
Deploy for development / testing
You can run the following command from within the
faas-netes/chart folder in the
$ helm upgrade --install openfaas openfaas/ \ --namespace openfaas \ --set functionNamespace=openfaas-fn
By default a NodePort will be created for the API Gateway.
If you're running on a cloud such as AKS or GKE you will need to pass an additional flag of
--set serviceType=LoadBalancer to tell
helm to create LoadBalancer objects instead. An alternative to using multiple LoadBalancers is to install an Ingress controller.
Deploy with an IngressController
In order to make use of automatic ingress settings you will need an IngressController in your cluster such as Traefik or Nginx.
--set ingress.enabled to enable ingress pass
--set ingress.enabled=true when running the installation via
By default services will be exposed with following hostnames (can be changed, see values.yaml for details):
SSL / TLS
If you require TLS/SSL then please make use of an IngressController. A full guide is provided to enable TLS for the OpenFaaS Gateway using cert-manager and Let's Encrypt.
Scaling up from zero replicas is enabled by default, to turn it off set
zero_scale to false in the helm chart.
Scaling to zero is done by the
faas-idler component and by default will only carry out a dry-run. Pass the following to helm to enable scaling to zero replicas of idle functions. You will also need to read the docs on how to configure functions to opt into scaling down.
Additional OpenFaaS options in
||Use the OpenFaaS operator CRD controller, default uses faas-netes as the Kubernetes controller||
||Functions namespace, preferred
||Type of external service to use
||Create ingress resources||
||Enable basic authentication on the Gateway||
||Queue worker read timeout||
||Queue worker write timeout||
||Image pull policy for deployed functions||
||Replicas of the gateway, pick more than
||Queue worker read timeout||
||Queue worker write timeout||
||Maximum duration of upstream function call, should be lower than
||Enables an intercepting proxy which will scale any function from 0 replicas to the desired amount||
||Replicas of the queue-worker, pick more than
||Max duration of any async task/request||
||Image pull policy for openfaas components, can change to
||Domain name of the Kubernetes cluster||
||Duration after which faas-idler will scale function down to 0||
||The time between each of reconciliation||
||When set to false the OpenFaaS API will be called to scale down idle functions, by default this is set to only print in the logs.||
Specify each parameter using the
--set key=value[,key=value] argument to
See values.yaml for detailed configuration.
Removing the OpenFaaS
All control plane components can be cleaned up with helm:
$ helm delete --purge openfaas
Follow this by the following to remove all other associated objects:
$ kubectl delete namespace/openfaas $ kubectl delete namespace/openfaas-fn
In some cases your additional functions may need to be either deleted before deleting the chart with
faas-cli or manually deleted using