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.
diff --git a/README.md b/README.md
index 52c9ac5..532f617 100644
--- a/README.md
+++ b/README.md
@@ -182,7 +182,11 @@
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 @@
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 @@
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 @@
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 @@
containerFactory:
dind: false
useRunc: false
- impl: "docker"
+ impl: "kubernetes"
enableConcurrency: false
networkConfig:
name: "bridge"
