Apache OpenWhisk is an open source, distributed serverless platform that executes functions in response to events at any scale.
The Apache OpenWhisk serverless platform supports a programming model in which developers write functional logic (called Actions), in any supported programming language, that can be dynamically scheduled and run in response to associated events (via Triggers) from external sources (Feeds) or from HTTP requests.
This chart will deploy the core OpenWhisk platform to your Kubernetes cluster. In its default configuration, the chart enables runtime support for executing actions written in NodeJS, Python, Swift, Java, PHP, Ruby, Go, Rust, .Net, and “blackbox” docker containers. The main components of the OpenWhisk platform are a front-end that provides a REST API to the user and the wsk
CLI, a CouchDB instance that stores user and system data, and a control plane that is responsible for scheduling incoming invocations of user actions onto dedicated Kubernetes worker nodes that have been labeled as “invoker nodes”.
Further documentation of the OpenWhisk system architecture, programming model, tutorials, and sample programs can all be found at on the Apache OpenWhisk project website.
In its default configuration, this chart will create the following Kubernetes resources:
All user interaction with OpenWhisk uses the REST API exposed by the nginx service via its NodePort ingress.
The chart requires one or more Kubernetes worker nodes to be designated to be used by OpenWhisk's invokers to execute user actions. These nodes are designated by being labeled with openwhisk-role=invoker
(see below for the kubectl
command).
If Container Image Security is enabled, you will not be able to download non-trusted container images. If this is the case, please add the following to the trusted registries so that these container images can be pulled during chart installation:
This chart requires 5 Persistent Volumes to be created to avoid loss of data. One of the following must be true to satisfy the Persistent Volume requirements for this chart:
k8s.persistence.enabled
is set to false to disable usage of Persistent Volumes (for development and test activities).k8s.persistence.hasDefaultStorageClass
is set to false
and k8s.persistence.explicitStorageClass
is set to a StorageClass which has an associated provisioner.OpenWhisk's Invokers need elevated security permissions to be able to create the containers that execute the user actions. Therefore, this chart requires a PodSecurityPolicy that permits host access to be bound to the target namespace prior to installation. If the default Pod security policy on your cluster is not restrictive then this step is not needed. If the default is restrictive, please create a new namespace with either a predefined PodSecurityPolicy ibm-anyuid-hostpath-psp
:
ibm-anyuid-hostpath-psp
Alternatively, you can have your cluster administrator setup a custom PodSecurityPolicy for you using the below definition:
Custom PodSecurityPolicy definition:
apiVersion: extensions/v1beta1 kind: PodSecurityPolicy metadata: name: ibm-anyuid-hostpath-psp annotations: kubernetes.io/description: "This policy allows pods to run with any UID and GID and any volume, including the host path. WARNING: This policy allows hostPath volumes. Use with caution." spec: allowPrivilegeEscalation: true fsGroup: rule: RunAsAny requiredDropCapabilities: - MKNOD allowedCapabilities: - SETPCAP - AUDIT_WRITE - CHOWN - NET_RAW - DAC_OVERRIDE - FOWNER - FSETID - KILL - SETUID - SETGID - NET_BIND_SERVICE - SYS_CHROOT - SETFCAP runAsUser: rule: RunAsAny seLinux: rule: RunAsAny supplementalGroups: rule: RunAsAny volumes: - '*'
Identify the Kubernetes worker nodes that should be used to execute user containers. Do this by labeling each node with openwhisk-role=invoker
. If you have a multi-node cluster, for each node <INVOKER_NODE_NAME> you want to be an invoker, execute
kubectl label nodes <INVOKER_NODE_NAME> openwhisk-role=invoker
For a single node cluster, simply do
kubectl label nodes --all openwhisk-role=invoker
Please ensure that you have reviewed the prerequisites and the initial setup instructions.
To install the chart using helm cli:
$ helm install <my-release> openwhisk --namespace <my-namespace> --create-namespace --set whisk.ingress.apiHostName=<cluster-ip-address>
The command deploys OpenWhisk on the Kubernetes cluster in the default configuration. The configuration section lists the parameters that can be configured during installation.
You can use the command helm status <my-release>
to get a summary of the various Kubernetes artifacts that make up your OpenWhisk deployment. Once the <my-release>-install-packages
Pod is in the Completed state, your OpenWhisk deployment is ready to be used.
Values.yaml outlines the configuration options that are supported by this chart.
To verify your deployment was successful, simply run:
helm test <my-release> --cleanup
To uninstall/delete the deployment:
$ helm delete <my-release>
The command removes all the Kubernetes components associated with the chart and deletes the release.
Documentation of the OpenWhisk system architecture, programming model, tutorials, and sample programs can all be found at on the Apache OpenWhisk project website.
For questions, hints, and tips for developing in Apache OpenWhisk: