This blog post introduces OpenFaaS Operator which is a CRD and Controller for OpenFaaS on Kubernetes. We started working on this in the community in October last year to enable a tighter integration with Kubernetes. The most visible way you’ll see this is by being able to type in
kubectl get functions.
Note: OpenFaaS Operator and Function CRD are features of OpenFaaS Pro & Enterprise. It is not available for the Community Edition (CE), where
faas-clior the REST API can be used to manage functions instead.
Brief history of Kubernetes support
OpenFaaS has worked natively with Kubernetes for well over a year. Each function you build creates a Docker image which when deployed through the OpenFaaS API creates a
Service API object and that in turn creates a number of
The original controller called
faas-netes was created by the community and much of its code has been re-purposed in the new Operator created by Stefan Prodan from Weaveworks. Since the Operator was created in October there have already been several pull requests, fixes and releases.
Here is a conceptual diagram from the documentation site. The Operator does not change this architecture, but changes the way it is created through listening to events.
The use of Kubernetes primitives from the beginning has meant users can use
kubectl to check logs, debug and monitor OpenFaaS functions in the same way they would any other Kubernetes resources. OpenFaaS runs on all Kubernetes services such as GKE, AKS, EKS, with OpenShift or with
Example: Using Weave Cloud to monitor network traffic, CPU and memory usage of OpenFaaS function Pods on GKE
I'm comparing Weave Cloud's integrated functions dashboard (CPU, memory, network, RED) for OpenFaaS with Grafana (light theme) and the community dashboard - Find out more about auto-scaling here 📈✅😀n- https://t.co/rddgNWGPkh @weaveworks @openfaas pic.twitter.com/j49k9slDC2— Alex Ellis (@alexellisuk) May 1, 2018
The OpenFaaS Operator
This section covers the technical and conceptual details of the OpenFaaS Operator.
What is a CRD?
One of the newer extension points in Kubernetes is the Custom Resource Definition (CRD) which allows developers to create their own native abstractions and extensions within the Kubernetes API. Why is that important? On its own the CRD is useful for storing objects and state which plays nicely with other Kubernetes objects, but it comes into its own with controllers.
A controller (sometimes called an operator) exists to create objects which the CRDs represent. It can run in a loop or react to events as they happen to reconcile a desired state with the actual state of the system.
$ kubectl get crd
In this example I can see the new functions definition created with the Operator’s helm-chart and the SealedSecrets definition from Bitnami.
$ kubectl get -n openfaas-fn functions
Example showing the functions deployed
At this point I could type in
kubectl delete -n openfaas-fn functions/figlet and in a few moments we would see the
figlet function, Pod and Service disappear from the OpenFaaS UI.
This is what a Kubernetes CRD entry for
v1alpha2) looks like:
You may have noticed a few differences between the YAML used by the
faas-cli and the YAML used by Kubernetes. You can still use your existing YAML with the
faas-cli, the CRD format is only needed if you will use
kubectl to create your functions.
Functions created by the
faas-clior OpenFaaS Cloud can still be managed through
- Does this replace
faas-netes? Will you continue to support
faas-netes project has the most active use and we will continue to support it within the community. All fixes and enhancements are being applied to both through Pull Requests.
- Who should use the new Operator?
Please try the new Operator in your development environment. The community would like your feedback on GitHub or Twitter.
Use the Operator if using CRDs is an important use-case for your project.
- Should I use the CRD YAML or the
Please continue to use the
faas-cli YAML unless you have a use-case which needs to create functions via
- Anything else I need to know?
The way you get the logs for the operator and gateway has changed slightly. See the troubleshooting guide in the docs.
Note from Stefan: If you migrate to the Operator you should first delete all your functions, then deploy them again after the update.
So what next?
If we can now use
kubectl to create functions then what does that mean for the OpenFaaS UI, CLI and the GitOps workflow with OpenFaaS Cloud?
At KubeCon in Austin Kelsey Hightower urged us not to go near
kubectlas developers. His point was that we should not be operating our clusters manually with access to potentially dangerous tooling.
kubectl and the
function CRD gives more power to those who need it and opens new extension points for future work and ideas. All the existing tooling is compatible, but it really becomes powerful when coupled with a “git push” GitOps CI/CD pipeline like OpenFaaS Cloud.
Try it out!
- Please try out the OpenFaaS Operator and let us know what you think
The helm chart has been re-published so follow the brief README here to get installed and upgraded today: https://github.com/openfaas/faas-netes/tree/master/chart/openfaas
Do you have questions, comments or suggestions? Tweet to @openfaas.
Want to support our work? You can become a sponsor as an individual or a business via GitHub Sponsors with tiers to suit every budget and benefits for you in return. Check out our GitHub Sponsors Page