Introducing the OpenFaaS Operator for Serverless on Kubernetes

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.

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.

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

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
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, Slack 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

Join the community

Within the OpenFaaS Slack community there are several key channels that are great for working with Kubernetes such as #kubernetes.

Here are some of the channels you could join after signing-up:

In OpenFaaS any programming language or binary is supported, but templates make them easy to consume via faas cli new, so join #templates and help us build the next set of templates for JVM-based languages.

#arm-and-pi

Building a cool Raspberry Pi Cluster or just struggling? Join this channel for help from the community and to share ideas and photos of your inventions.

Join #contributors to start giving back to Open Source and to become a part of the project. Get started here