kata-deploy
provides a Dockerfile, which contains all of the binaries
and artifacts required to run Kata Containers, as well as reference DaemonSets, which can
be utilized to install Kata Containers on a running Kubernetes cluster.
Note, installation through DaemonSets successfully installs katacontainers.io/kata-runtime
on
a node only if it uses either containerd or CRI-O CRI-shims.
$ cd $GOPATH/src/github.com/kata-containers/kata-containers/tools/packaging/kata-deploy
$ kubectl apply -f kata-rbac/base/kata-rbac.yaml
$ kubectl apply -f kata-deploy/base/kata-deploy.yaml
or on a k3s cluster:
$ cd $GOPATH/src/github.com/kata-containers/kata-containers/tools/packaging/kata-deploy
$ kubectl apply -k kata-deploy/overlays/k3s
Workloads specify the runtime they'd like to utilize by setting the appropriate runtimeClass
object within
the Pod
specification. The runtimeClass
examples provided define a node selector to match node label katacontainers.io/kata-runtime:"true"
,
which will ensure the workload is only scheduled on a node that has Kata Containers installed
runtimeClass
is a built-in type in Kubernetes. To apply each Kata Containers runtimeClass
:
$ cd $GOPATH/src/github.com/kata-containers/kata-containers/tools/packaging/kata-deploy/runtimeclasses
$ kubectl apply -f kata-runtimeClasses.yaml
The following YAML snippet shows how to specify a workload should use Kata with Cloud Hypervisor:
spec:
template:
spec:
runtimeClassName: kata-clh
The following YAML snippet shows how to specify a workload should use Kata with Firecracker:
spec:
template:
spec:
runtimeClassName: kata-fc
The following YAML snippet shows how to specify a workload should use Kata with QEMU:
spec:
template:
spec:
runtimeClassName: kata-qemu
To run an example with kata-clh
:
$ cd $GOPATH/src/github.com/kata-containers/kata-containers/tools/packaging/kata-deploy/examples
$ kubectl apply -f test-deploy-kata-clh.yaml
To run an example with kata-fc
:
$ cd $GOPATH/src/github.com/kata-containers/kata-containers/tools/packaging/kata-deploy/examples
$ kubectl apply -f test-deploy-kata-fc.yaml
To run an example with kata-qemu
:
$ cd $GOPATH/src/github.com/kata-containers/kata-containers/tools/packaging/kata-deploy/examples
$ kubectl apply -f test-deploy-kata-qemu.yaml
The following removes the test pods:
$ cd $GOPATH/src/github.com/kata-containers/kata-containers/tools/packaging/kata-deploy/examples
$ kubectl delete -f test-deploy-kata-clh.yaml
$ kubectl delete -f test-deploy-kata-fc.yaml
$ kubectl delete -f test-deploy-kata-qemu.yaml
$ cd $GOPATH/src/github.com/kata-containers/kata-containers/tools/packaging/kata-deploy
$ kubectl delete -f kata-deploy/base/kata-deploy.yaml
$ kubectl apply -f kata-cleanup/base/kata-cleanup.yaml
$ kubectl delete -f kata-cleanup/base/kata-cleanup.yaml
$ kubectl delete -f kata-rbac/base/kata-rbac.yaml
$ kubectl delete -f runtimeclasses/kata-runtimeClasses.yaml
The Dockerfile used to create the container image deployed in the DaemonSet is provided here. This image contains all the necessary artifacts for running Kata Containers, all of which are pulled from the Kata Containers release page.
Host artifacts:
cloud-hypervisor
,firecracker
,qemu-system-x86_64
, and supporting binariescontainerd-shim-kata-v2
kata-collect-data.sh
kata-runtime
Virtual Machine artifacts:
kata-containers.img
andkata-containers-initrd.img
: pulled from Kata GitHub releases pagevmlinuz.container
andvmlinuz-virtiofs.container
: pulled from Kata GitHub releases page
Two DaemonSets are introduced for kata-deploy
, as well as an RBAC to facilitate
applying labels to the nodes.
This DaemonSet installs the necessary Kata binaries, configuration files, and virtual machine artifacts on
the node. Once installed, the DaemonSet adds a node label katacontainers.io/kata-runtime=true
and reconfigures
either CRI-O or containerd to register three runtimeClasses
: kata-clh
(for Cloud Hypervisor isolation), kata-qemu
(for QEMU isolation),
and kata-fc
(for Firecracker isolation). As a final step the DaemonSet restarts either CRI-O or containerd. Upon deletion,
the DaemonSet removes the Kata binaries and VM artifacts and updates the node label to katacontainers.io/kata-runtime=cleanup
.
This DaemonSet runs of the node has the label katacontainers.io/kata-runtime=cleanup
. These DaemonSets removes
the katacontainers.io/kata-runtime
label as well as restarts either CRI-O or containerd
systemctl
daemon. You cannot execute these resets during the preStopHook
of the Kata installer DaemonSet,
which necessitated this final cleanup DaemonSet.