To fully participate in the workshop, you will require access to a Kubernetes cluster with the following properties:
- Version >= v1.12 kubernetes
- That is scratch/disposable (i.e. not a live cluster you care about)
- That supports virtualisation (Kata runs containers in VMs, so the
kubeletmust be running on a node that is able to run a VM. - see below) - preferably CRI-O installed as the CRI runtime on the cluster, along with the matching
runcas the default container runtime.- Kata Containers also works with
containerd, but the workshop demo will be conducted on a stack configured withCRI-O. you are welcome to follow along withcontainerdand adapt as necessary if you wish. See this page
- Kata Containers also works with
- Preferably your stack will have the Kubernetes
RuntimeClassFeatureGate enabled on both the APIserver and the kubelet. The workshop will discuss how to enable this FeatureGate, but it may be easier to enable this at cluster setup time.
There are a few methods that can be used to obtain a local (on your local machine) k8s stack setup and ready to use for the workshop. A remote cloud instance may also be useable, as long as it can support virtualisation (which implies it is either a bare metal machine or supports nested virtualisation).
To enable kata under minikube on a Linux host, we need to add a few configuration options to the default minikube setup. This is nice
and easy, as minikube supports them on the setup commandline.
Note, afaik, minikube on a Mac does not support nested virtualisation, so will not satisfy the requirements. Having said that,
you should still be able to follow along with the configuration and installation of Kata, but won't be able to launch any Kata containers themselves.
Here are the features, and why we need them:
| what | why |
|---|---|
| --vm-driver kvm2 | The host VM driver I tested with |
| --cpus 4 | Bump up from default of 2 if you have the capacity, just for perf |
| --memory 6144 | Allocate more memory, as Kata containers default to 1 or 2Gb |
| --feature-gates=RuntimeClass=true | Kata needs to use the RuntimeClass k8s feature |
| --network-plugin=cni | As recommended for minikube CRI-o |
| --enable-default-cni | As recommended for minikube CRI-o |
| --container-runtime=cri-o | Using CRI-O for Kata |
| --bootstrapper=kubeadm | As recommended for minikube CRI-o |
for minikube specific installation instructions see the docs,
which will also help locate the information needed to get the kvm2 driver installed etc.
Here then is the command I ran to get my basic minikube set up ready to add kata:
minikube start \
--vm-driver kvm2 \
--cpus 4 \
--memory 6144 \
--feature-gates=RuntimeClass=true \
--network-plugin=cni \
--enable-default-cni \
--container-runtime=cri-o \
--bootstrapper=kubeadmThat command will take a little while to pull down and install items, but ultimately should complete successfully.
NOTE: I had some challenges on my machine getting all the relevant
vagrantitems set up to use this stackup. I would therefore recommend, if you can, you start by trying to set up the aboveminikubestack first to see if that will satisfy your requirements.
Clear Linux provides a convinient vagrant based 3-node stack setup as an example of a Kata Kubernetes deployment. We
can utilise this stack for this workshop.
Download the setup scripts from this github repo.
Read the Documentation, and stop at the "Join workers to the cluster" stage. It is recommended you do join at least one of the slave nodes to the master node cluster.
Setup the initial stack like:
$ cd cloud-native-setup/clr-k8s-examples
$ ./create_stack.sh minimal
# And follow the onscreen instructions and documentationYour node needs to have virtualisation enabled, to allow kubelet to launch Kata VMs.
To check if you have virtualisation enabled on the node, try:
$ egrep --color 'vmx|svm' /proc/cpuinfoand look for vmx or svm coloured red in the output.