There are a few things to prepare before installing OpenFaaS. Namespaces and a secret.

Namespaces

Create and configure two namespaces, one for the OpenFaaS core services openfaas and a second for the functions openfaas-fn.

kubectl apply -f https://raw.githubusercontent.com/openfaas/faas-netes/master/namespaces.yml

The created namespaces may be listed.

kubectl get namespaces

If you are curious, scan the contents of the namespace creating YAML. Labels are added to the namespaces.

curl https://raw.githubusercontent.com/openfaas/faas-netes/master/namespaces.yml.

OpenFaaS Access Secret

Generate and submit a Kubernetes secret for basic authentication for the gateway. The secret is named basic-auth and OpenFaaS will use that key when it prompts you for access.

PASSWORD=$(head -c 12 /dev/urandom | shasum | cut --delimiter=' ' --fields=1 | head -c 4)

The random password is shortened to just 4 characters for these demonstration purposes. Normally head -c 4 would be omitted.

kubectl -n openfaas create secret generic basic-auth --from-literal=basic-auth-user=admin --from-literal=basic-auth-password=$PASSWORD

OpenFaaS requires a container registry during the build, push and deploy phases. It defaults to using Docker Hub, but there is no need to shuttle private images over the internet. Instead, we keep all this pushing and pulling in a local registry.

It's helpful to have a container image registry during the build, push, and deploy phases. There is no need to shuttle private images over the internet. Instead, we keep all this pushing and pulling in a local registry.

There are many options for standing up a container registry. We prefer a pure Kubernetes solution and install a registry through the Docker Registry Helm Chart.

Add the chart repository for the Helm chart to be installed:

helm repo add twuni https://helm.twun.io

Install the chart for a private container image registry:

helm install registry twuni/docker-registry \
  --version 1.10.0 \
  --namespace kube-system \
  --set service.type=NodePort \
  --set service.nodePort=31500

The registry is now available as a service. It can be listed:

kubectl get service --namespace kube-system

Assign an environment variable to the common registry location:

export REGISTRY=[[HOST_SUBDOMAIN]]-31500-[[KATACODA_HOST]].environments.katacoda.com

It will be a few moments before the registry deployment reports it's Available (1):

kubectl get deployments registry-docker-registry --namespace kube-system

Once the registry is serving, inspect the contents of the empty registry:

curl $REGISTRY/v2/_catalog | jq -c

and you will see this registry response with the expected empty array:

{"repositories":[]}

If you do not see this response, wait a few moments, and try again. If you have waited and continue to receive an error message, then return to step one and re-verify the health of the cluster.

OpenFaaS can be installed using Helm. Helm is a package manager for Kubernetes that was previously installed and ready for your instructions.

A common Helm chart is predefined for installing OpenFaaS. Popular incubating and stable charts appear in the curated Helm chart repository and there are plans to move OpenFaaS there. For now, a repo add command will allow Helm to find the OpenFaaS chart.

helm repo add openfaas https://openfaas.github.io/faas-netes/

Install the OpenFaaS operator chart referenced from that repository.

helm upgrade openfaas --install openfaas/openfaas \
  --version 6.0.0 \
  --namespace openfaas \
  --set functionNamespace=openfaas-fn \
  --set operator.create=true \
  --set basic_auth=true \
  --set rbac=false \
  --set faasIdler.dryRun=false \
  --set faasIdler.inactivityDuration=10s

The dryRun property is set to false so we can explore scaling near the end of this course.

Watch the 7 deployments for OpenFaaS become Available. In about a minute all the Available status column will turn from 0 to 1 as each deployment becomes active.

watch kubectl get deployments --namespace=openfaas

The installation is complete once all the Deployments have reached an Available state of 1. Use this clear to break out of the watch or press Ctrl+C.

These instructions have been adopted from the openfaas-operator.

A common way to interact with OpenFaaS is from the command line. Install the OpenFaaS command-line interface (CLI) tool.

curl -SLs cli.openfaas.com | sudo sh

When you see the ASCII logo and the version the faas-cli tool will be ready.

faas-cli list

However, faas-cli cannot work until you login to the gateway. Commands like this will report unauthorized access.

At this point there is an OpenFaaS gateway providing access to both the portal and REST API to manage the functions and OpenFaaS. Most of the CLI commands require this gateway as a parameter. To reduce the verbosity the gateway here is stored as an environment variable.

export OPENFAAS_URL=https://[[HOST_SUBDOMAIN]]-31112-[[KATACODA_HOST]].environments.katacoda.com/

Notice the port 31112. This is the Kubernetes NodePort of the external-gateway OpenFaaS service. The service can be see using this list command.

kubectl get service --namespace openfaas

With this gateway access, the first action is to login. We will use the same password that was submitted in the previous preparation step.

faas-cli login --username admin --password="$PASSWORD"

Now the list command will show an empty list found behind the gateway.

faas-cli list

To access the portal use the same user name (admin) and password that was applied in the preparation step for the secret creation. Reveal the password.

echo -e "The OpenFaaS portal will need these credentials when prompted:\nuser: admin\npassword: $PASSWORD"

Instead of using the CLI tool you can also interact with OpenFaaS through its portal. On the right, there is a tab called OpenFaaS Portal or it can be accessed from this link: https://[[HOST_SUBDOMAIN]]-31112-[[KATACODA_HOST]].environments.katacoda.com/

For visibility and understanding, leave this tab open for the subsequent steps.

OpenFaaS is now ready to do some work.

Store Functions

A variety of pre-built functions are available in the OpenFaaS store. The Function Store is a curated index of OpenFaaS functions which have been tested by the community and chosen for their experience. List the functions in the store.

faas-cli store list

Deploy the Cows function and invoke it a few times.

faas-cli store deploy "ASCII Cows"

echo 10 | faas-cli invoke cows

We hope this is an utterly mooving experience for you. If not, ruminate on the next step.

Loading a Library

You can register a bundle of pre-built functions by submitting a single YAML file. See how these pre-defined functions are declared.

curl https://raw.githubusercontent.com/openfaas/faas/master/stack.yml

Submit this declaration to OpenFaaS and the functions will be available.

faas-cli deploy -f https://raw.githubusercontent.com/openfaas/faas/master/stack.yml

View the functions that were just submitted.

faas-cli list --verbose

You can also ask Kubernetes to list the same functions.

kubectl get services,pods --namespace openfaas-fn

One of the functions is Markdown. Here are two ways to invoke the function.

echo Hi | faas-cli invoke markdown

The first time this is invoked it takes a few moments for the Deployment to initialize, but once invoke the subsequent calls are fast.

uname -a | faas-cli invoke markdown

Notice how OpenFaaS tracks how many times the markdown function was invoked in the Invocations column.

faas-cli list --verbose

The Replicas columns relates to performance and scaling that will be explored in an upcoming step.

Kubernetes Resources

In Kubernetes notice all these functions are now represented by deployments in the openfaas-fn namespace.

kubectl get deployments --namespace openfaas-fn

Additionally, they all have services load balancing for the function pods.

kubectl get service --namespace openfaas-fn

The previous step invoked a pre-defined function. Let's create a new function and invoke it.

New or updated OpenFaaS functions progress through distinct phases before they can run: Create, Build, Push and Deploy. The later Build, Push and Deploy often is converged into a single up command.

Create

Create the structure and files for the new function.

faas-cli new fibonacci --lang python3 --prefix $REGISTRY/fibonacci --gateway $OPENFAAS_URL

In the current directory, there is a pre-written Fibonacci Python code example. Notice at the top is the "handle" method that OpenFaaS expects as a signature for the function.

ccat fibonacci.py

Copy the example Python code into the generated directory.

cp fibonacci.py fibonacci/handler.py

Build, Push and Deploy

With the function coded and defined deploy the artifacts to OpenFaaS and it will take care of all the server details for you, after all it's serverless.

faas-cli up -f fibonacci.yml

Once built, the image will be in the container registry.

curl $REGISTRY/v2/_catalog | jq

Invoke

With the new function deployed OpenFaaS took care of bundling it into a container and instructing Kubernetes to create a Pod and Service so it can start handling requests.

Invoke the new function with this command.

echo 5 | faas-cli invoke fibonacci

If you update the function logic, then redeploy with the --update=false --replace switches.

faas-cli up -f fibonacci.yml --update=false --replace

The new version of the function will normally be available in 5-10 seconds.

A good system will have features in place to observe its status, health, and activity. Prometheus is a de facto solution for monitoring the metrics of Kubernetes clusters and its applications. Prometheus is a time series database and with it, various metrics of the functions can be stored over time and observed. The OpenFaaS Helm chart includes an installation of Prometheus. OpenFaaS also is configured to expose to Prometheus key metrics of the functions and its management.

Prometheus

The Helm chart sets up a Prometheus service, but it's not exposed. The Prometheus service can be exposed by changing the service from a ClusterIP type to a NodePort type.

kubectl patch service prometheus --namespace=openfaas --type='json' --patch='[{"op": "replace", "path": "/spec/type","value":"NodePort"}]'

then change the NodePort value to a known port above 30000

kubectl patch service prometheus --namespace=openfaas --type='json' --patch='[{"op": "replace", "path": "/spec/ports/0/nodePort", "value":31120}]'

With these changes, you can view the Prometheus Portal. On the right, there is a tab called Prometheus or from this link: https://[[HOST_SUBDOMAIN]]-31120-[[KATACODA_HOST]].environments.katacoda.com/

Alert Manager

As above, the Helm chart also sets up an AlertManager service. It is also not exposed. The AlertManager service can be exposed by changing the service from a ClusterIP type to a NodePort type.

kubectl patch service alertmanager --namespace=openfaas --type='json' --patch='[{"op": "replace", "path": "/spec/type","value":"NodePort"}]'

then change the NodePort value to a known port above 30000

kubectl patch service alertmanager --namespace=openfaas --type='json' --patch='[{"op": "replace", "path": "/spec/ports/0/nodePort", "value":31121}]'

With these changes, you can view the Alertmanager Portal. On the right, there is a tab called Alerts or from this link: https://[[HOST_SUBDOMAIN]]-31121-[[KATACODA_HOST]].environments.katacoda.com/

Grafana

It's also helpful to have a good dashboard to see how well the functions are running and how OpenFaaS is scaling the load.

There is a helpful Grafana container configured for OpenFaaS found here. Install this Grafana.

kubectl -n openfaas run \ --image=stefanprodan/faas-grafana:4.6.3 \ --port=3000 \ grafana

Expose the dashboard as a service on a known port.

kubectl -n openfaas expose pod grafana --type=NodePort --name=grafana

kubectl patch service grafana --namespace=openfaas --type='json' --patch='[{"op": "replace", "path": "/spec/ports/0/nodePort", "value":31122}]'

With these changes you can view the Grafana dashboard. On the right, there is a tab called Grafana or from this link: https://[[HOST_SUBDOMAIN]]-31122-[[KATACODA_HOST]].environments.katacoda.com/dashboard/db/openfaas

The default credentials are admin/admin.

Deploy the figlet function.

faas-cli store deploy figlet --label "com.openfaas.scale.zero=true"

Notice the label passed in ensures the functions deployed, but the Pod is not running. A key feature of functions is when idle, consume no resources and upon activity scale up hot instances. When activity quiets the Pods are released. OpenFaaS manages these scaling details for you, based on load metrics metered to Prometheus.

Exercise the figlet function.

curl -X POST https://[[HOST_SUBDOMAIN]]-31112-[[KATACODA_HOST]].environments.katacoda.com/function/figlet -d 'No Fluff Just Stuff is transcendent'

Put some load on the function by repeating the request in a loop.

while [ true ]; do curl -sw 'Total: %{time_total}s\n' https://[[HOST_SUBDOMAIN]]-31112-[[KATACODA_HOST]].environments.katacoda.com/function/figlet -d 'NFJS'; done;

Navigate to the Grafana dashboard and notice the rising Replica scaling value. OpenFaaS is not scaling up new function instances to handle the increased load. Go to the OpenFaaS portal and notice the rising of the replicas with all the invocation counts. Go to the Kubernetes dashboard and in the openfaas-fn namespaces notice all the pods that are scaled up to handle the load.

Use this clear to break out of the watch or press Ctrl+C.

Now that the activity has stopped, quickly start this watch.

watch kubectl get pods -n openfaas-fn

Notice the figlet Pods are scaling down (Terminating) as the activity calms down. The Pods will scale to one and after another 10 seconds (this was a Helm chart parameter) of no activity, the single hot Pod will be removed to a resting scale of zero. When all is quiet, the functions still accept activity, yet no resources are consumed.

This exercise is adopted from lab 9 found here.

Alex Ellis demonstrates scaling in this video.