{"id":13566601,"url":"https://github.com/apache/openwhisk-deploy-kube","last_synced_at":"2025-04-07T14:11:10.148Z","repository":{"id":38349664,"uuid":"91608763","full_name":"apache/openwhisk-deploy-kube","owner":"apache","description":"The Apache OpenWhisk Kubernetes Deployment repository supports deploying the Apache OpenWhisk system on Kubernetes and OpenShift clusters.","archived":false,"fork":false,"pushed_at":"2024-09-24T14:22:35.000Z","size":1248,"stargazers_count":302,"open_issues_count":63,"forks_count":233,"subscribers_count":42,"default_branch":"master","last_synced_at":"2025-03-31T13:15:26.774Z","etag":null,"topics":["apache","cloud","docker","faas","functions","functions-as-a-service","kubernetes","openshift","openwhisk","serverless","serverless-architectures","serverless-functions"],"latest_commit_sha":null,"homepage":"https://openwhisk.apache.org/","language":"Shell","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/apache.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE.txt","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2017-05-17T18:38:26.000Z","updated_at":"2025-02-22T02:48:01.000Z","dependencies_parsed_at":"2024-08-01T02:12:21.889Z","dependency_job_id":"f12efd32-56ad-4d64-9e9d-9975efe32bd4","html_url":"https://github.com/apache/openwhisk-deploy-kube","commit_stats":{"total_commits":453,"total_committers":66,"mean_commits":6.863636363636363,"dds":"0.36644591611479027","last_synced_commit":"108f327580f04c51dc4b29ac0beff024cfd6f2f9"},"previous_names":[],"tags_count":1,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/apache%2Fopenwhisk-deploy-kube","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/apache%2Fopenwhisk-deploy-kube/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/apache%2Fopenwhisk-deploy-kube/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/apache%2Fopenwhisk-deploy-kube/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/apache","download_url":"https://codeload.github.com/apache/openwhisk-deploy-kube/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":247666008,"owners_count":20975787,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["apache","cloud","docker","faas","functions","functions-as-a-service","kubernetes","openshift","openwhisk","serverless","serverless-architectures","serverless-functions"],"created_at":"2024-08-01T13:02:12.861Z","updated_at":"2025-04-07T14:11:10.130Z","avatar_url":"https://github.com/apache.png","language":"Shell","funding_links":[],"categories":["Shell"],"sub_categories":[],"readme":"\u003c!--\n#\n# Licensed to the Apache Software Foundation (ASF) under one or more\n# contributor license agreements.  See the NOTICE file distributed with\n# this work for additional information regarding copyright ownership.\n# The ASF licenses this file to You under the Apache License, Version 2.0\n# (the \"License\"); you may not use this file except in compliance with\n# the License.  You may obtain a copy of the License at\n#\n#     http://www.apache.org/licenses/LICENSE-2.0\n#\n# Unless required by applicable law or agreed to in writing, software\n# distributed under the License is distributed on an \"AS IS\" BASIS,\n# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.\n# See the License for the specific language governing permissions and\n# limitations under the License.\n#\n--\u003e\n\n# OpenWhisk Deployment on Kubernetes\n\n[![License](https://img.shields.io/badge/license-Apache--2.0-blue.svg)](http://www.apache.org/licenses/LICENSE-2.0)\n[![Build Status](https://travis-ci.com/apache/openwhisk-deploy-kube.svg?branch=master)](https://travis-ci.com/github/apache/openwhisk-deploy-kube)\n[![Join Slack](https://img.shields.io/badge/join-slack-9B69A0.svg)](http://slack.openwhisk.org/)\n\nApache OpenWhisk is an open source, distributed Serverless platform\nthat executes functions (fx) in response to events at any scale.  The\nOpenWhisk platform supports a programming model in which developers\nwrite functional logic (called Actions), in any supported programming\nlanguage, that can be dynamically scheduled and run in response to\nassociated events (via Triggers) from external sources (Feeds) or from\nHTTP requests.\n\nThis repository supports deploying OpenWhisk to Kubernetes and OpenShift.\nIt contains a Helm chart that can be used to deploy the core\nOpenWhisk platform and optionally some of its Event Providers\nto both single-node and multi-node Kubernetes and OpenShift clusters.\n\n# Table of Contents\n\n* [Prerequisites: Kubernetes and Helm](#prerequisites-kubernetes-and-helm)\n* [Deploying OpenWhisk](#deploying-openwhisk)\n* [Administering OpenWhisk](#administering-openwhisk)\n* [Development and Testing OpenWhisk on Kubernetes](#development-and-testing-openwhisk-on-kubernetes)\n* [Cleanup](#cleanup)\n* [Issues](#issues)\n\n# Prerequisites: Kubernetes and Helm\n\n[Kubernetes](https://kubernetes.io/) is a container orchestration\nplatform that automates the deployment, scaling, and management of\ncontainerized applications. [Helm](https://helm.sh/) is a package\nmanager for Kubernetes that simplifies the management of Kubernetes\napplications. You do not need to have detailed knowledge of either Kubernetes or\nHelm to use this project, but you may find it useful to review their\nbasic documentation to become familiar with their key concepts and terminology.\n\n## Kubernetes\n\nYour first step is to create a Kubernetes cluster that is capable of\nsupporting an OpenWhisk deployment. Although there are some [technical\nrequirements](docs/k8s-technical-requirements.md) that the Kubernetes\ncluster must satisfy, any of the options described below is\nacceptable.\n\n### Simple Docker-based options\n\nThe simplest way to get a small Kubernetes cluster suitable for\ndevelopment and testing is to use one of the Docker-in-Docker\napproaches for running Kubernetes directly on top of Docker on your\ndevelopment machine.  Configuring Docker with 4GB of memory and\n2 virtual CPUs is sufficient for the default settings of OpenWhisk.\nDepending on your host operating system, we recommend the following:\n1. MacOS: Use the built-in Kubernetes support in Docker for Mac\nversion 18.06 or later. Please follow our\n[setup instructions](docs/k8s-docker-for-mac.md) to initially create\nyour cluster.\n2. Linux: Use [kind](https://github.com/kubernetes-sigs/kind).\nPlease follow our [setup instructions](docs/k8s-kind.md)\nto initially create your cluster.\n3. Windows: Use the built-in Kubernetes support in Docker for Windows\nversion 18.06 or later. Please follow our\n[setup instructions](docs/k8s-docker-for-windows.md) to initially create\nyour cluster.\n\n### Using a Kubernetes cluster from a cloud provider\n\nYou can also provision a Kubernetes cluster from a cloud provider,\nsubject to the cluster meeting the [technical\nrequirements](docs/k8s-technical-requirements.md). You will need at least\n1 worker node with 4GB of memory and 2 virtual CPUs to deploy the default\nconfiguration of OpenWhisk.  You can deploy to significantly larger clusters\nby scaling up the replica count of the various components and labeling multiple\nnodes as invoker nodes. We have\ndetailed documentation on using Kubernetes clusters from the following\nmajor cloud providers:\n* [IBM (IKS)](docs/k8s-ibm-public.md)\n* [Google (GKE)](docs/k8s-google.md)\n* [Amazon (EKS)](docs/k8s-aws.md)\n\nWe would welcome contributions of documentation for Azure (AKS) and any other public cloud providers.\n\n### Using OpenShift\n\nYou will need at least 1 worker node with 4GB of memory and 2 virtual\nCPUs to deploy the default configuration of OpenWhisk.  You can deploy\nto significantly larger clusters by scaling up the replica count of\nthe various components and labeling multiple nodes as invoker nodes.\nFor more detailed documentation, see:\n* [OpenShift 4](docs/openshift-4.md)\n\n### Using a Kubernetes cluster you built yourself\n\nIf you are comfortable with building your own Kubernetes clusters and\ndeploying services with ingresses to them, you should also\nbe able to deploy OpenWhisk to a do-it-yourself cluster. Make sure\nyour cluster meets the [technical requirements](docs/k8s-technical-requirements.md).\nYou will need at least 1 worker node with 4GB of memory and 2 virtual CPUs to deploy\nthe default configuration of OpenWhisk.  You can deploy to\nsignificantly larger clusters by scaling up the replica count of the\nvarious components and labeling multiple nodes as invoker nodes.\n\nAdditional more detailed instructions:\n* [Some general comments](docs/k8s-diy.md).\n* [Using kubeadm on Ubuntu 18.04](docs/k8s-diy-ubuntu.md).\n\n## Helm\n\n[Helm](https://github.com/kubernetes/helm) is a tool to simplify the\ndeployment and management of applications on Kubernetes clusters.\nThe OpenWhisk Helm chart requires Helm 3.\n\nOur automated testing currently uses Helm v3.2.4\n\nFollow the Helm [install instructions](https://github.com/kubernetes/helm)\nfor your platform to install Helm v3.0.1 or newer.\n\n# Deploying OpenWhisk\n\nNow that you have your Kubernetes cluster and have installed\nthe Helm 3 CLI, you are ready to deploy OpenWhisk.\n\n## Overview\n\nYou will use Helm to deploy OpenWhisk to your Kubernetes cluster.\nThere are four deployment steps that are described in more\ndetail below in the rest of this section.\n1. [Initial cluster setup](#initial-setup). If you have provisioned a\nmulti-node cluster, you should label the worker nodes\nto indicate their intended usage by OpenWhisk.\n2. [Customize the deployment](#customize-the-deployment). You will\ncreate a `mycluster.yaml` that specifies key facts about your\nKubernetes cluster and the OpenWhisk configuration you wish to\ndeploy. Predefined `mycluster.yaml` files for common flavors\nof Kubernetes clusters are provided in the [deploy](./deploy)\ndirectory.\n3. [Deploy OpenWhisk with Helm](#deploy-with-helm). You will use Helm and\n`mycluster.yaml` to deploy OpenWhisk to your Kubernetes cluster.\n4. [Configure the `wsk` CLI](#configure-the-wsk-cli). You need to\ntell the `wsk` CLI how to connect to your OpenWhisk deployment.\n\n## Initial setup\n\n### Single Worker Node Clusters\n\nIf your cluster has a single worker node, then you should\nconfigure OpenWhisk without node affinity. This is done by adding\nthe following lines to your `mycluster.yaml`\n```\naffinity:\n  enabled: false\n\ntoleration:\n  enabled: false\n\ninvoker:\n  options: \"-Dwhisk.kubernetes.user-pod-node-affinity.enabled=false\"\n```\n\n### Multi Worker Node Clusters\n\nIf you are deploying OpenWhisk to a cluster with multiple worker\nnodes, we recommend using node affinity to segregate the compute nodes\nused for the OpenWhisk control plane from those used to execute user\nfunctions. Do this by labeling each node with\n`openwhisk-role=invoker`. In the default configuration, which uses the\nKubernetesContainerFactory, the node labels are used in conjunction\nwith Pod affinities to inform the Kubernetes scheduler how to place\nwork so that user actions will not interfere with the OpenWhisk\ncontrol plane.  When using the non-default DockerContainerFactory,\nOpenWhisk assumes it has exclusive use of these invoker nodes and will\nschedule work on them directly, completely bypassing the Kubernetes\nscheduler. For each node\n\u003cINVOKER_NODE_NAME\u003e you want to be an invoker, execute\n```shell\nkubectl label node \u003cINVOKER_NODE_NAME\u003e openwhisk-role=invoker\n```\n\nIf you are targeting OpenShift, use the command\n```shell\noc label node \u003cINVOKER_NODE_NAME\u003e openwhisk-role=invoker\n```\n\nFor more precise control of the placement of the rest of OpenWhisk's\npods on a multi-node cluster, you can optionally label additional\nnon-invoker worker nodes. Use the label `openwhisk-role=core`\nto indicate nodes which should run the OpenWhisk control plane\n(the controller, kafka, zookeeeper, and couchdb pods).\nIf you have dedicated Ingress nodes, label them with\n`openwhisk-role=edge`. Finally, if you want to run the OpenWhisk\nEvent Providers on specific nodes, label those nodes with\n`openwhisk-role=provider`.\n\nIf the Kubernetes cluster does not allow you to assign a label to a\nnode, or you cannot use the affinity attribute, you use the yaml\nsnippet shown above in the single worker node configuration to disable\nthe use of affinities by OpenWhisk.\n\n## Customize the Deployment\n\nYou will need a `mycluster.yaml` file to record key aspects of your\nKubernetes cluster that are needed to configure the deployment of\nOpenWhisk to your cluster. For details, see the documentation\nappropriate to your Kubernetes cluster:\n* [Docker for Mac](docs/k8s-docker-for-mac.md#configuring-openwhisk)\n* [Docker for Windows](docs/k8s-docker-for-windows.md#configuring-openwhisk)\n* [kind](docs/k8s-kind.md#configuring-openwhisk)\n* [IBM Cloud Kubernetes Service (IKS)](docs/k8s-ibm-public.md#configuring-openwhisk)\n* [Google (GKE)](docs/k8s-google.md#configuring-openwhisk)\n* [Amazon (EKS)](docs/k8s-aws.md#configuring-openwhisk)\n* [OpenShift](docs/openshift-4.md##configuring-openwhisk)\n\nDefault/template `mycluster.yaml` for various types of Kubernetes clusets\ncan be found in subdirectories of [deploy](./deploy).\n\nBeyond the basic Kubernetes cluster specific configuration information,\nthe `mycluster.yaml` file can also be used\nto customize your OpenWhisk deployment by enabling optional features\nand controlling the replication factor of the various microservices\nthat make up the OpenWhisk implementation. See the [configuration\nchoices documentation](./docs/configurationChoices.md) for a\ndiscussion of the primary options.\n\n## Deploy With Helm\n\nFor simplicity, in this README, we have used `owdev` as the release name and\n`openwhisk` as the namespace into which the Chart's resources will be deployed.\nYou can use a different name and/or namespace simply by changing the commands\nused below.\n\n**NOTE:** The commands below assume Helm v3.2.0 or higher. Verify your local Helm version with the command `helm version`.\n\n### Deploying Released Charts from Helm Repository\n\nThe OpenWhisk project maintains a Helm repository at `https://openwhisk.apache.org/charts`.\nYou may install officially released versions of OpenWhisk from this repository:\n\n```\nhelm repo add openwhisk https://openwhisk.apache.org/charts\nhelm repo update\nhelm install owdev openwhisk/openwhisk -n openwhisk --create-namespace -f mycluster.yaml\n```\n\n### Deploying from Git\n\nTo deploy directly from sources, either download the\n[latest source release](https://github.com/apache/openwhisk-deploy-kube/releases) or\n`git clone https://github.com/apache/openwhisk-deploy-kube.git` and use the Helm chart\nfrom the `helm/openwhisk` folder of the source tree.\n\n```shell\nhelm install owdev ./helm/openwhisk -n openwhisk --create-namespace -f mycluster.yaml\n```\n\n### Checking status\n\nYou can use the command `helm status owdev -n openwhisk` to get a summary\nof the various Kubernetes artifacts that make up your OpenWhisk\ndeployment. Once the pod name containing the word `install-packages` is in the `Completed` state,\nyour OpenWhisk deployment is ready to be used.\n\n**NOTE:** You can check the status of the pod by running the following command `kubectl get pods -n openwhisk --watch`.\n\n## Configure the wsk CLI\n\nConfigure the OpenWhisk CLI, wsk, by setting the auth and apihost\nproperties (if you don't already have the wsk cli, follow the\ninstructions [here](https://github.com/apache/openwhisk-cli)\nto get it). Replace `whisk.ingress.apiHostName` and `whisk.ingress.apiHostPort`\nwith the actual values from your `mycluster.yaml`.\n```shell\nwsk property set --apihost \u003cwhisk.ingress.apiHostName\u003e:\u003cwhisk.ingress.apiHostPort\u003e\nwsk property set --auth 23bc46b1-71f6-4ed5-8c54-816aa4f8c502:123zO3xZCLrMN6v2BKK1dXYFpXlPkccOFqm12CdAsMgRU4VrNZ9lyGVCGuMDGIwP\n```\n### Configuring the CLI for Kubernetes on Docker for Mac and Windows\n\nThe `docker0` network interface does not exist in the Docker for Mac/Windows\nhost environment. Instead, exposed NodePorts are forwarded from localhost\nto the appropriate containers.  This means that you will use `localhost`\ninstead of `whisk.ingress.apiHostName` when configuring\nthe `wsk` cli and replace `whisk.ingress.apiHostPort`\nwith the actual values from your `mycluster.yaml`.\n\n```shell\nwsk property set --apihost localhost:\u003cwhisk.ingress.apiHostPort\u003e\nwsk property set --auth 23bc46b1-71f6-4ed5-8c54-816aa4f8c502:123zO3xZCLrMN6v2BKK1dXYFpXlPkccOFqm12CdAsMgRU4VrNZ9lyGVCGuMDGIwP\n```\n\n## Verify your OpenWhisk Deployment\n\nYour OpenWhisk installation should now be usable.  You can test it by following\n[these instructions](https://github.com/apache/openwhisk/blob/master/docs/actions.md)\nto define and invoke a sample OpenWhisk action in your favorite programming language.\n\nYou can also issue the command `helm test owdev -n openwhisk` to run the basic\nverification test suite included in the OpenWhisk Helm chart.\n\nNote: if you installed self-signed certificates, which is the default\nfor the OpenWhisk Helm chart, you will need to use `wsk -i` to\nsuppress certificate checking.  This works around `cannot validate\ncertificate` errors from the `wsk` CLI.\n\nIf your deployment is not working, check our\n[troubleshooting guide](./docs/troubleshooting.md) for ideas.\n\n## Scale-up your OpenWhisk Deployment\n\nUsing defaults, your deployment is configured to provide a bare-minimum working platform for testing and exploration. For your specialized workloads, you can scale-up your openwhisk deployment by defining your deployment configurations in your `mycluster.yaml` which overrides the defaults in `helm/openwhisk/values.yaml`. Some important parameters to consider (for other parameters, check `helm/openwhisk/values.yaml` and [configurationChoices](./docs/configurationChoices.md)):\n* `actionsInvokesPerminute`: limits the maximum number of invocations per minute.\n* `actionsInvokesConcurrent`: limits the maximum concurrent invocations.\n* `containerPool`: total memory available per `invoker` instance. `Invoker` uses this memory to create containers for user-actions. The concurrency-limit (actions running in parallel) will depend upon the total memory configured for `containerPool` and memory allocated per action (`default:` 256mb per container).\n\nFor more information about increasing concurrency-limit, check [scaling-up your deployment](./docs/k8s-custom-build-cluster-scaleup.md).\n\n# Administering OpenWhisk\n\n[Wskadmin](https://github.com/apache/openwhisk/tree/master/tools/admin) is the tool to perform various administrative operations against an OpenWhisk deployment.\n\nSince wskadmin requires credentials for direct access to the database (that is not normally accessible to the outside), it is deployed in a pod inside Kubernetes that is configured with the proper parameters. You can run `wskadmin` with `kubectl`. You need to use the `\u003cnamespace\u003e` and the deployment `\u003cname\u003e` that you configured with `--namespace` and `--name` when deploying.\n\nYou can then invoke `wskadmin` with:\n\n```\nkubectl -n \u003cnamespace\u003e -ti exec \u003cname\u003e-wskadmin -- wskadmin \u003cparameters\u003e\n```\n\nFor example, is your deployment name is `owdev` and the namespace is `openwhisk` you can list users in the `guest` namespace with:\n\n```\n$ kubectl -n openwhisk  -ti exec owdev-wskadmin -- wskadmin user list guest\n23bc46b1-71f6-4ed5-8c54-816aa4f8c502:123zO3xZCLrMN6v2BKK1dXYFpXlPkccOFqm12CdAsMgRU4VrNZ9lyGVCGuMDGIwP\n```\n\nCheck [here](https://github.com/apache/openwhisk/tree/master/tools/admin) for details about the available commands.\n\n# Development and Testing OpenWhisk on Kubernetes\n\nThis section outlines how common OpenWhisk development tasks are\nsupported when OpenWhisk is deployed on Kubernetes using Helm.\n\n### Running OpenWhisk test cases\n\nSome key differences in a Kubernetes-based deployment of OpenWhisk are\nthat deploying the system does not generate a `whisk.properties` file and\nthat the various internal microservices (`invoker`, `controller`,\netc.) are not directly accessible from the outside of the Kubernetes cluster.\nTherefore, although you can run full system tests against a\nKubernetes-based deployment by giving some extra command line\narguments, any unit tests that assume direct access to one of the internal\nmicroservices will fail.   First clone the [core OpenWhisk repository](https://github.com/apache/openwhisk)\nlocally and set `$OPENWHISK_HOME` to its top-level directory. Then, the\nsystem tests can be executed in a\nbatch-style as shown below, where WHISK_SERVER and WHISK_AUTH are\nreplaced by the values returned by `wsk property get --apihost` and\n`wsk property get --auth` respectively.\n```shell\ncd $OPENWHISK_HOME\n./gradlew :tests:testSystemKCF -Dwhisk.auth=$WHISK_AUTH -Dwhisk.server=https://$WHISK_SERVER -Dopenwhisk.home=`pwd`\n```\nYou can also launch the system tests as JUnit test from an IDE by\nadding the same system properties to the JVM command line used to\nlaunch the tests:\n```shell\n -Dwhisk.auth=$WHISK_AUTH -Dwhisk.server=https://$WHISK_SERVER -Dopenwhisk.home=`pwd`\n```\n\n**NOTE:** You need to install JDK 8 in order to run these tests.\n\n### Deploying a locally built docker image.\n\nIf you are using Kubernetes in Docker, it is\nstraightforward to deploy local images by adding a stanza to your\nmycluster.yaml. For example, to use a locally built controller image,\njust add the stanza below to your `mycluster.yaml` to override the default\nbehavior of pulling a stable `openwhisk/controller` image from Docker Hub.\n```yaml\ncontroller:\n  imageName: \"whisk/controller\"\n  imageTag: \"latest\"\n```\n\n### Selectively redeploying using a locally built docker image\n\nYou can use the `helm upgrade` command to selectively redeploy one or\nmore OpenWhisk components.  Continuing the example above, if you make\nadditional changes to the controller source code and want to just\nredeploy it without redeploying the entire OpenWhisk system you can do\nthe following:\n\nIf you are using a multi-node Kubernetes cluster you will need to\nrepeat the following steps on all nodes that may run the controller\ncomponent.\n\nThe first step is to rebuild the docker image:\n```shell\n# Execute this command in your openwhisk directory\nbin/wskdev controller -b\n```\nNote that the ```wskdev``` flags ```-x``` and ```-d``` are not compatible\nwith the Kubernetes deployment of OpenWhisk.\n\nAlternatively, you can build all of the OpenWhisk docker components:\n```shell\n# Execute this command in your openwhisk directory\n./gradlew distDocker\n```\n\nAfter building the new docker image(s), tag the new image:\n```shell\n# Tag the docker image you seek to redeploy\ndocker tag whisk/controller whisk/controller:v2\n```\n\nThen, edit your `mycluster.yaml` to contain:\n```yaml\ncontroller:\n  imageName: \"whisk/controller\"\n  imageTag: \"v2\"\n```\nRedeploy with Helm by executing this command in your\nopenwhisk-deploy-kube directory:\n```shell\nhelm upgrade owdev ./helm/openwhisk -n openwhisk -f mycluster.yaml\n```\n\n### Deploying Lean Openwhisk version.\n\nTo have a lean setup (no Kafka, Zookeeper and no Invokers as separate entities):\n```yaml\ncontroller:\n  lean: true\n```\n\n# Cleanup\n\nUse the following command to remove all the deployed OpenWhisk components:\n```shell\nhelm uninstall owdev -n openwhisk\n```\nBy default, `helm uninstall` removes the history of previous deployments.\nIf you want to keep the history, add the command line flag `--keep-history`.\n\n# Issues\n\nIf your OpenWhisk deployment is not working, check our\n[troubleshooting guide](./docs/troubleshooting.md) for ideas.\n\nReport bugs, ask questions and request features [here on GitHub](../../issues).\n\nYou can also join our slack channel and chat with developers. To get access to our slack channel, request an invite [here](http://slack.openwhisk.org).\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fapache%2Fopenwhisk-deploy-kube","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fapache%2Fopenwhisk-deploy-kube","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fapache%2Fopenwhisk-deploy-kube/lists"}