How to use Kata Containers and CRI-O with Kubernetes¶
Prerequisites¶
This guide requires Kata Containers available on your system, install-able by following this guide.
Install a CRI implementation¶
Kubernetes CRI (Container Runtime Interface) implementations allow using any OCI-compatible runtime with Kubernetes, such as the Kata Containers runtime.
Kata Containers support both the CRI-O and
containerd CRI implementations. We choose CRI-O for our examples in this guide.
CRI-O¶
For CRI-O installation instructions, refer to the CRI-O Tutorial page.
The following sections show how to set up the CRI-O snippet configuration file (default path: /etc/crio/crio.conf) for Kata.
Unless otherwise stated, all the following settings are specific to the crio.runtime table:
# The "crio.runtime" table contains settings pertaining to the OCI
# runtime used and options for how to set up and manage the OCI runtime.
[crio.runtime]
Note: After any change to this file, the CRI-O daemon have to be restarted with:
Kubernetes Runtime Class (CRI-O v1.12+)¶
The Kubernetes Runtime Class
is the preferred way of specifying the container runtime configuration to run a Pod's containers.
To use this feature, Kata must added as a runtime handler. This can be done by dropping a 50-kata
snippet file into /etc/crio/crio.conf.d, with the content shown below:
[crio.runtime.runtimes.kata]
runtime_path = "/usr/bin/containerd-shim-kata-v2"
runtime_type = "vm"
runtime_root = "/run/vc"
privileged_without_host_devices = true
Install Kubernetes¶
Depending on what your needs are and what you expect to do with Kubernetes, please refer to the following documentation to install it correctly.
Kubernetes talks with CRI implementations through a container-runtime-endpoint,
also called CRI socket. This socket path is different depending on which CRI
implementation you chose, and the Kubelet service has to be updated accordingly.
Configure for CRI-O¶
/etc/systemd/system/kubelet.service.d/0-crio.conf
[Service]
Environment="KUBELET_EXTRA_ARGS=--container-runtime=remote --runtime-request-timeout=15m --container-runtime-endpoint=unix:///var/run/crio/crio.sock"
Run a Kubernetes pod with Kata Containers¶
After you update your Kubelet service based on the CRI implementation you are using, reload and restart Kubelet. Then, start your cluster:
$ sudo systemctl daemon-reload
$ sudo systemctl restart kubelet
# If using CRI-O
$ sudo kubeadm init --ignore-preflight-errors=all --cri-socket /var/run/crio/crio.sock --pod-network-cidr=10.244.0.0/16
---
kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
cgroupDriver: cgroupfs
podCIDR: "10.244.0.0/16"
EOF
$ sudo kubeadm init --ignore-preflight-errors=all --config kubeadm-config.yaml
$ export KUBECONFIG=/etc/kubernetes/admin.conf
Allow pods to run in the control-plane node¶
By default, the cluster will not schedule pods in the control-plane node. To enable control-plane node scheduling:
Create runtime class for Kata Containers¶
Users can use RuntimeClass to specify a different runtime for Pods.
$ cat > runtime.yaml <<EOF
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
name: kata
handler: kata
EOF
$ sudo -E kubectl apply -f runtime.yaml
Run pod in Kata Containers¶
If a pod has the runtimeClassName set to kata, the CRI plugin runs the pod with the
Kata Containers runtime.
- Create an pod configuration that using Kata Containers runtime
$ cat << EOF | tee nginx-kata.yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx-kata
spec:
runtimeClassName: kata
containers:
- name: nginx
image: nginx
EOF
- Create the pod
- Check pod is running
- Check hypervisor is running