This is an automated email from the ASF dual-hosted git repository.
dgrove pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/openwhisk-deploy-kube.git
The following commit(s) were added to refs/heads/master by this push:
new d3d2fe5 switch default to KubernetesContainerFactory (#547)
d3d2fe5 is described below
commit d3d2fe531266ee8387d1d29378e44e377fb4dedb
Author: David Grove <[email protected]>
AuthorDate: Mon Nov 18 10:10:50 2019 -0500
switch default to KubernetesContainerFactory (#547)
With the continuing shift to containerd or cri-o based runtimes
and decrease in direct use of Docker on the Kubernetes worker nodes,
we're seeing a large spike in user problems. By switching the default
values, we should increase the odds of an OpenWhisk deploy on Kubernetes
working out of the box without requiring a sophisticated understanding
of Kube and OpenWhisk.
---
README.md | 6 +++++-
docs/configurationChoices.md | 8 +++++---
docs/troubleshooting.md | 11 +++++++++++
helm/openwhisk/values.yaml | 2 +-
4 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/README.md b/README.md
index 52c9ac5..532f617 100644
--- a/README.md
+++ b/README.md
@@ -182,7 +182,11 @@ tell the `wsk` CLI how to connect to your OpenWhisk
deployment.
Indicate the Kubernetes worker nodes that should be used to execute
user containers by OpenWhisk's invokers. Do this by labeling each node with
-`openwhisk-role=invoker`. In its default configuration,
+`openwhisk-role=invoker`. In the default configuration, which uses the
+KubernetesContainerFactory, the node labels are used in conjunction
+with Pod affinities to inform the Kubernetes scheduler how to place
+work so that user actions will not interfere with the OpenWhisk
+control plane. When using the non-default DockerContainerFactory,
OpenWhisk assumes it has exclusive use of these invoker nodes and
will schedule work on them directly, completely bypassing the Kubernetes
scheduler. For a single node cluster, simply do
diff --git a/docs/configurationChoices.md b/docs/configurationChoices.md
index da0d12a..9232a98 100644
--- a/docs/configurationChoices.md
+++ b/docs/configurationChoices.md
@@ -163,9 +163,10 @@ component on Kubernetes (selected by picking a
advantages of this configuration are lower latency on container
management operations and robustness of the code paths being
used (since they are the same as in the default system). The
- primary disadvantage is that it does not leverage Kubernetes to
+ primary disadvantages are (1) that it does not leverage Kubernetes to
simplify resource management, security configuration, etc. for
- user containers.
+ user containers and (2) it cannot be used if the underlying
+ container engine is containerd or cri-o.
2. `KubernetesContainerFactory` is a truly Kubernetes-native design
where although the Invoker is still responsible for managing the
cache of available user containers, the Invoker relies on Kubernetes to
@@ -174,7 +175,8 @@ component on Kubernetes (selected by picking a
inverse of `DockerContainerFactory`. Kubernetes pod management
operations have higher latency and without additional configuration
(see below) can result in poor performance. However, this design
- fully leverages Kubernetes to manage the execution resources for user
functions.
+ fully leverages Kubernetes to manage the execution resources for
+ user functions.
You can control the selection of the ContainerFactory by adding either
```yaml
diff --git a/docs/troubleshooting.md b/docs/troubleshooting.md
index 787675b..ee14953 100644
--- a/docs/troubleshooting.md
+++ b/docs/troubleshooting.md
@@ -38,6 +38,17 @@ mounting`/sys/fs/cgroup`,
`/run/runc`,`/var/lib/docker/containers`, or
value in `helm/openwhisk/templates/_invoker-helpers.yaml` to match the host
operating system
running on your Kubernetes worker node.
+### Invokers unhealthy when using DockerContainerFactory
+
+It is becoming increasingly common for Kubernetes clusters to be
+configured to be using something other than Docker as the underlying
+container runtime engine (eg containerd or cri-o). The
+DockerContainerFactory cannot be used on such clusters. The usual
+symptom is that the invoker pods deploy correctly, but the controller
+considers all invokers to be unheathy/down because even though the
+invoker pod is running, it is unable to successfully spawn user action
+containers. The workaround is to use the KubernetesContainerFactory.
+
### Kafka, Redis, CouchDB, and Zookeeper pods stuck in Pending
These pods all mount Volumes via PersistentVolumeClaims. If there is a
diff --git a/helm/openwhisk/values.yaml b/helm/openwhisk/values.yaml
index c1ca71c..01af015 100644
--- a/helm/openwhisk/values.yaml
+++ b/helm/openwhisk/values.yaml
@@ -261,7 +261,7 @@ invoker:
containerFactory:
dind: false
useRunc: false
- impl: "docker"
+ impl: "kubernetes"
enableConcurrency: false
networkConfig:
name: "bridge"
