Deploy OpenFaaS in Production

    When deploying OpenFaaS it is recommended that you use . A managed Kubernetes service such as GKE, EKS is recommended if you are using public cloud. You can also deploy to your own infrastructure.

    These instructions apply for both Kubernetes and OpenShift 3.x.

    The default configuration for Kubernetes is to store secrets in base64, some users may want to encrypt their secrets at rest. By enabling this configuration, the secrets used by OpenFaaS will also be encrypted at rest.

    Chart options

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

    Depending on your existing usage of or your preferences you may not want to use the Tiller component of helm. In this case you can use in the deployment guide to generate YAML files to apply on your cluster.

    You will find each helm chart option documented in the OpenFaaS chart:

    See also:

    High-availability (HA)

    It is recommended that you have high-availability for the OpenFaaS components including:

    • OpenFaaS gateway

    The gateway supports more than one replica and can be auto-scaled with HPAv2

    • OpenFaaS queue-worker

    Scale the queue worker replicas according to the maximum level of asynchronous tasks you want to process in parallel.

    You may also want to set a minimum availability level for each function of > 1.

    See the chart options for how to set the number of replicas.

    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.

    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

    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. If you are not sure which to use, then use faas-netes.

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

    Production stage:

    1. openfaas
    2. openfaas-fn

    Assume that no suffix means that the environment or stage is for production deployments.

    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:

    Heptio Contour also includes automatic retries and additional Ingress extensions which you may find useful:

    • Check any default timeouts set for your IngressController
    • Check any default timeout values set for your cloud LoadBalancer

    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.

    You may want to configure NetworkPolicy to restrict communication between the openfaas Functions namespace and the core components of OpenFaaS. This is dependent on using a network driver which supports NetworkPolicy such as Weavenet.

    See also: an example from OpenFaaS Cloud

    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. Options include clustering NATS and MySQL.

    See also:

    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.

    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.

    It is recommended that you use a read-only filesystem. You will still be able to write to

    Use secrets and environmental variables appropriately

    • Secrets are for confidential data

    Example: API key, IP address, username

    Example: verbose logging, runtime mode, timeout values