You can run Kubernetes on top of Docker on Linux, MacOS, and Windows using the
kind project.
Based on using Docker-in-Docker (DIND) virtualization and
kubeadm
, kind can be used to create a virtual multi-node
Kubernetes cluster that is suitable for deploying
OpenWhisk for development and testing. For detailed instructions on kind, we
refer you to that project's github repository.
Here we will only cover the basic operations needed to create and
operate a default cluster with two virtual worker nodes.
Download the latest stable release of kind
for your platform from
https://github.com/kubernetes-sigs/kind/releases. Our TravisCI testing
currently uses kind v0.11.1 on an ubuntu 18.04 host.
On Linux, make sure your userid is in the docker
group on the host
machine. This will enable you to run kind
without
requiring sudo
to gain root
privileges.
We've provided a script
that you can use to bring up a kind cluster in a
reasonable configuration for OpenWhisk. The script
assumes that port 31001 is available on your machine
and can be used by openwhisk. To use a different port,
edit deploy/kind/kind-cluster.yaml
.
./deploy/kind/start-kind.sh
Assuming you used the default port 31001 when starting kind, a [mycluster.yaml](../deploy/kind/mycluster.yaml] for a standard deployment of OpenWhisk would be:
whisk:
ingress:
type: NodePort
apiHostName: localhost
apiHostPort: 31001
useInternally: false
nginx:
httpsNodePort: 31001
# disable affinity
affinity:
enabled: false
toleration:
enabled: false
invoker:
options: "-Dwhisk.kubernetes.user-pod-node-affinity.enabled=false"
# must use KCF as kind uses containerd as its container runtime
containerFactory:
impl: "kubernetes"
Note that you must use the KubernetesContainerFactory when running
OpenWhisk on kind
because it is configured to use containerd
as the underlying container engine.
External to the Kubernetes cluster, for example when using the wsk
cli,
we will use the port forwarding configured by the extraPortMappings
in kind-cluster.yaml to allow the
OpenWhisk apihost property to be set to localhost:31001
If you are working on the core OpenWhisk system and want
to use a locally built controller, invoker, or scheduler image
to test your changes, you need to push the image to the docker image
repository inside the kind
cluster.
For example, suppose I had a local change to the controller
I wanted to test. To do this, I would build the image normally
(gradlew distDocker
in openwhisk
). Then, execute the kind
command
kind load docker-image whisk/controller
Then add a stanza to your mycluster.yaml
to override the default
behavior of pulling a stable openwhisk/controller
image from Docker Hub.
controller:
imageName: "whisk/controller"
imageTag: "latest"
Then deploy OpenWhisk normally using helm install
. The deployed
system will use the locally built whisk/controller
image.
Using kind is only appropriate for development and testing purposes. It is not recommended for production deployments of OpenWhisk.
TLS termination will be handled by OpenWhisk's nginx
service and
will use self-signed certificates. You will need to invoke wsk
with
the -i
command line argument to bypass certificate checking.
Unlike using Kubernetes with Docker for Mac 18.06 and later, only the
virtual master/worker nodes are visible to Docker on the host system. The
individual pods running the OpenWhisk system are only visible using
kubectl
and not directly via host Docker commands.