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-cli or 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 Deployment and Service API object and that in turn creates a number of Pods.

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.

OpenFaaS Conceptual Overview

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 kubeadm.

Example: Using Weave Cloud to monitor network traffic, CPU and memory usage of OpenFaaS function Pods on GKE

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
NAME                        AGE
functions.openfaas.com      41d
sealedsecrets.bitnami.com   41d

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
NAME       AGE
figlet     55m
nodeinfo   55m

Example showing the functions deployed

OpenFaaS UI with CRDs

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.

YAML definition

This is what a Kubernetes CRD entry for functions.openfaas.com (version v1alpha2) looks like:

apiVersion: openfaas.com/v1alpha2
kind: Function
metadata:
  name: nodeinfo
  namespace: openfaas-fn
spec:
  name: nodeinfo
  image: functions/nodeinfo:latest
  labels:
    com.openfaas.scale.min: "2"
    com.openfaas.scale.max: "15"
  environment:
    write_debug: "true"
  limits:
    cpu: "200m"
    memory: "1Gi"
  requests:
    cpu: "10m"
    memory: "128Mi"

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-cli or OpenFaaS Cloud can still be managed through kubectl.

Q&A

  • Does this replace faas-netes? Will you continue to support faas-netes?

The 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 faas-cli YAML definition?

Please continue to use the faas-cli YAML unless you have a use-case which needs to create functions via kubectl.

  • 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 kubectl as developers. His point was that we should not be operating our clusters manually with access to potentially dangerous tooling.

Access to 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

Alex Ellis

Founder of @openfaas.