Kata Containers is an open source project that provides a secure container
runtime with lightweight virtual machines that feel and perform like containers,
but provide stronger workload isolation using hardware virtualization technology
as a second layer of defense.
Similar to the OCI runtime runc provided by Docker, Cilium can be used with
Kata Containers, providing a higher degree of security at the network layer and
at the compute layer with Kata.
This guide provides a walkthrough of installing Kata with Cilium on GCE.
Kata Containers on Google Compute Engine (GCE) makes use of nested virtualization.
At the time of this writing, nested virtualization support was not yet available
on GKE.

As mentioned before, Kata Containers on Google Compute Engine (GCE) makes use of
nested virtualization. As a prerequisite you need to create an image with
nested virtualization enabled in your currently active GCE project.

Select an image based on project and family rather than by name. This ensures
any scripts or other automation always works with a non-deprecated image,
including security updates, updates to GCE-specific scripts, etc.

Kata Containers runtime is an OCI compatible runtime and cannot directly interact
with the CRI API level. For this reason we rely on a CRI implementation to translate
CRI into OCI. There are two supported ways called CRI-O and CRI-containerd.
It is up to you to choose the one that you want, but you have to pick one.

If you select CRI-O, follow the “CRI-O Tutorial” instructions
here to properly install it.
If you select containerd with cri plugin, follow the “Getting Started for Developers”
instructions here to properly install it.

Setup your Kubernetes environment and make sure the following requirements are met:

Refer to the section Requirements for detailed instruction on how to
prepare your Kubernetes environment.

Note

Minimum version of kubernetes 1.12 is required to use the RuntimeClass Feature
for Kata Container runtime described below. It is possible to use kubernetes<=1.10
with Kata, but that requires for a slightly different setup that has been
deprecated.

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.

Kubernetes configured with CRI runtimes by default uses runc runtime for running a
workload. You will need to configure Kubernetes to be able to use an alternate runtime.

RuntimeClass
is a Kubernetes feature first introduced in Kubernetes 1.12 as alpha. It is the
feature for selecting the container runtime configuration to use
to run a pod’s containers.
To use Kata-Containers, ensure the RuntimeClass feature gate is enabled for k8s < 1.13.
It is enabled by default on k8s 1.14.
See Feature Gates
for an explanation of enabling feature gates.

To install Kata Containers and configure CRI to use Kata as a one step process,
you will use kata-deploy
tool as shown below.

This will install all the required Kata binaries under /opt/kata and configure
CRI implementation with the RuntimeClass handlers for the Kata runtime binaries.
Kata Containers can leverage Qemu and Firecracker hypervisor for running
the lightweight VM. kata-fc binary runs a Firecracker isolated Kata Container while
kata-qemu runs a Qemu isolated Kata Container.