Deploy OpenFaaS Pro in Production¶
OpenFaaS is meant for open-source developers, but OpenFaaS Pro is meant for production.
This page contains recommendations for tuning OpenFaaS Pro for production usage.
Did you know?
We offer an initial onboarding call for OpenFaaS Pro users, or a more detailed review as part of our Enterprise Support package.
Decide on your Kubernetes flavour¶
OpenFaaS Pro requires Kubernetes.
It's recommended that you use a managed service from a public cloud provider such as GKE, AWS EKS or Digital Ocean Kubernetes. You can also deploy to your own infrastructure in the cloud or privately, on-premises.
These instructions apply for both Kubernetes, however OpenShift 3.x and 4.x are compatible with some additional tuning, which you can request via support.
Advanced Kubernetes configuration¶
-
Encrypting Secret Data at Rest (optional)
The default configuration for Kubernetes is to store secrets in base64 which is equivalent to plaintext and is not a form of encryption. Kubernetes supports encrypting secrets at rest and because OpenFaaS uses Kubernetes secrets, its secrets will also be encrypted at rest.
Helm Charts¶
The helm chart is the most flexible way to deploy OpenFaaS and allows you to customize many different options such as whether scale-to-zero is enabled, how many replicas to have of each component and what kind of healthchecks or probes to use.
You will find each helm chart option documented in the OpenFaaS chart:
See also: OpenFaaS Chart
The chart is compatible with GitOps-style tooling such as Flux and ArgoCD. We recommend using one of these tools to manage your deployment of OpenFaaS declaratively.
Note that some optional components such as the Kafka event-connector and cron-connector have their own separate helm charts.
Take advantage of the OpenFaaS Pro add-ons¶
Check out the overview to see what is available to you under your license:
High-availability (HA)¶
It is recommended that you have high-availability for the OpenFaaS components including:
-
OpenFaaS gateway
For a production environment, we recommend a minimum of three replicas of the gateway. You can set an additional auto-scaling rule with HPAv2 if you have purchased additional licenses for that environment.
-
OpenFaaS queue-worker
The queue worker is responsible for processing asynchronous invocations. It's recommended to run at least two replicas of this service. Each queue worker can potentially run hundreds of invocations concurrently, and can be configured with different queues per function if required.
See the faas-netes chart for more options on the above.
Endpoint load-balancing¶
Endpoint load-balancing is where OpenFaaS distributes load between functions using the endpoints of each function replica in the cluster.
You should use this as a default, but if you use a service mesh you will need to turn it off because a service mesh manages this for you using its own proxy.
Configure timeouts¶
Configure each timeout as appropriate for your workloads. If you expect all functions or endpoints to return within a few seconds then set a timeout to accommodate that. If you expect all workloads to run for several minutes then bear that in mind with your values.
Note: You may have a timeout configured in your IngressController or cloud LoadBalancer. See your documentation or contact your administrator to check the value and make sure they are in-sync.
See also: Expanded timeouts
Configure function health-check probes¶
There are two types of health-check probes: exec and http. The default in the helm chart is exec for backwards-compatibility.
It is recommended to use httpProbes by default which are more CPU efficient than exec probes. If you are using Istio with mutual TLS then you will need to use exec probes.
Configure function health-check interval¶
There are both liveness and readiness checks for functions. If you are using the scale-from-zero feature then you may want to set these values as low as possible, however this may require additional CPU. A sensible default would be something that makes sense for your own use-case. Tune each value as needed.
Non-root user for functions¶
Set the non-root user flag so that every function is forced to run in a restricted security context.
Choose the operator or faas-netes¶
The faas-netes controller for OpenFaaS is the most mature, well tested and supported.
You may also use the OpenFaaS Operator if you would like to use a Function CRD, which is required for GitOps-style tooling like Flux and ArgoCD.
If you are not sure which to use, then faas-netes is a good choice.
See the helm chart for more.
Single or multi-stage?¶
Now decide if you want to create a single or multi-stage environment. In a single-stage environment a cluster has only one OpenFaaS installation and is either staging, production or something else. In a multi-stage environment a cluster may have several installations of OpenFaaS where each represents a different stage.
Single-stage¶
Since you have a single stage or environment you can apply the namespaces YAML file from the faas-netes repo. This will create two namespaces:
- openfaas
- openfaas-fn
Multiple-stages¶
In a multiple stage environment you may have OpenFaaS installed several times - one for each stage such as "staging" and "production".
In this case take a copy of the namespaces YAML file and edit it once per each environment such as:
Staging stage:
openfaas-staging
openfaas-staging-fn
Production stage:
openfaas
openfaas-fn
Assume that no suffix means that the environment or stage is for production deployments.
Find out more here: Configure your OpenFaaS functions for staging and production
Configure networking¶
Whether you need to configure new networking for your OpenFaaS deployments, or integrate into existing systems the following guidelines should be followed.
Configure Ingress¶
See also: Ingress
It is recommended that you use an IngressController and TLS so that traffic between your clients and your OpenFaaS Gateway is encrypted.
You may already have opinions about what IngressController you want to use, the maintainers like to use Nginx given its broad adoption and relative ubiquity.
See also: Nginx IngressController
Heptio Contour also includes automatic retries and additional Ingress extensions which you may find useful:
See also: Heptio Contour
Notes:
- Check any default timeouts set for your IngressController
- Check any default timeout values set for your cloud LoadBalancer
Pin IP addresses with floating IPs (optional)¶
Most cloud providers allow users to allocate a permanent IP address or Virtual/Floating IP to provisioned LoadBalancers. It is recommended that you do this for production usage. For AWS EKS, this doesn't apply due to the use of a CNAME for LoadBalancers.
TLS¶
Depending on your infrastructure or cloud provider you may choose to add TLS termination in your LoadBalancer, with some other external software or hardware or in the IngressController's configuration. For public-facing OpenFaaS installations the maintainers recommend the use of cert-manager from JetStack.
mTLS¶
There was a conscious decision made not to bake a service mesh into OpenFaaS, however it is very easy to add one to enable mutual TLS between functions and the gateway.
You can enable mutual TLS (mTLS) between OpenFaaS services using Linkerd or Istio, the community prefers Linkerd for its low resource consumption and ease of use.
Reduce DNS lookups when calling other functions¶
By default, Kubernetes will search for a name like gateway with every domain and local domain extension within /etc/hosts, which could lead to dozens of DNS lookups per outgoing HTTP call from a function.
To make this most efficient, always address the gateway using its complete name:
http://gateway.openfaas.svc.cluster.local:8080/function/function-name
The suffix is usually svc.cluster.local, however, this can vary between clusters.
Configure NetworkPolicy¶
You may want to configure NetworkPolicy to restrict communication between the openfaas Functions namespace and the core components of OpenFaaS.
This is to prevent unauthorized or unintended access to the core components of OpenFaaS (the control plane) by functions deployed by your users.
This is dependent on using a network driver which supports NetworkPolicy such as Weave Net or Calico.
See also: an example from OpenFaaS Cloud
NATS Streaming (asynchronous invocations)¶
If you are using the asynchronous invocations available in OpenFaaS then you may want to ensure high-availability or persistence for NATS Streaming. The default configuration uses in-memory storage which means if the NATS Pod crashes or is relocated to another node, you may lose messages.
The easiest way to make NATS durable for production is to turn it off in the OpenFaaS chart, and to install it separately using the NATS Operator or helm chart using a Persistent Volume or SQL as a backend.
See also: NATS documentation
Workload or function guidelines¶
OpenFaaS supports two types of workloads - a microservice or a function. If you are implementing your own microservice or template then ensure that you are complying with the workload contract as per the docs.
See also: workload contract
Pick your watchdog version¶
For each function it is recommended to evaluate whether the classic or of-watchdog is best suited to your use-case.
For high-throughput, low-latency operations you may prefer to use the of-watchdog.
See also: watchdog
Use a non-root user¶
Each template authored by the OpenFaaS Project already uses a non-root user, but if you have your own templates then ensure that they are running as a non-root user to help mitigate against vulnerabilities.
Enable a read-only filesystem¶
It is recommended that you use a read-only filesystem. You will still be able to write to /tmp/
Use secrets and environmental variables appropriately¶
Find out more here: Configure your OpenFaaS functions for staging and production
-
Secrets are for confidential data
Example: API key, IP address, username
-
Environmental variables are for non-confidential configuration data
Example: verbose logging, runtime mode, timeout values
Reach out for a review¶
Did you know?
We offer an initial onboarding call for OpenFaaS Pro users, or a more detailed review as part of our Enterprise Support package.