DEV Community: Kiki Fachry

Using Kata Containers as a Container Runtime in OpenStack Zun

Kiki Fachry — Sun, 06 Apr 2025 16:32:50 +0000

As container adoption grows in cloud infrastructure, OpenStack has introduced Zun, a project designed to manage application containers natively within the OpenStack ecosystem. By default, Zun leverages container runtimes like runc, but for users seeking stronger isolation and enhanced security, integrating Kata Containers offers a compelling upgrade. With Kata, containers launched via Zun gain the security advantages of lightweight virtual machines—each with its own kernel—without giving up the flexibility and speed that make containers so attractive. In this post, we'll explore how Kata Containers can be used with Zun to provide a secure and efficient container experience within OpenStack.

Topology

In this case, we will deploy OpenStack using Kolla-Ansible in all-in-one mode and set Kata Containers as a container runtime for Zun. Here is the topology

Here is the topology explaination :

eno1 and eno2 wil configured as a bonding interface (802.3ad) named bond0.
in bond0 we will create an VLAN interface with ID 100 ( bond0.100 ) for management and access the OpenStack services. This adapter has an IP address.
bond0 will configured for external network adapter. We will using VLAN as an external network in ml2.conf. This adapter doesn't have any IP address.
OpenStack will deployed using Kolla-ansible with docker for container service
Docker and Containerd will need additional coniguration to add kata as a runtime

Prerequisites

Let's breakdown the prerequisites before start the deployment

CPU with virtualization support
64-bit Linux host ( must be using nested virtualization if using VM ) with multiple network adapters. In this case, we will using Ubuntu 24.04 and several network adapters ( explained at topology section )
Internet access
Sudo user

Pre-installation

Disable any swap

swapoff -a

Don't forget to delete swap partition entry in /etc/fstab to make sure the swap partition will not active when booting.

Enable br_netfilter module

Load br_netfilter kernel module

modprobe br_netfiter

Create a new file under /etc/modules-load.d/ and add br_netfilter to make sure the module will automatically loaded when booting

echo 'br_netfilter' > /etc/modules-load.d/must-loaded.conf

Installation

1. Kata Containers Installation

We will start with install Kata Containers. In this case, we will install Kata Containers with Docker. So, we will execute kata-manager.sh file with -D options.

./kata-manager.sh -D

Or you can install only Kata Containers and install Docker separately by using -o options.

./kata-manager.sh -o

Also, you can change default hypervisor for Kata Containers from qemu to another such as firecracker, cloud-hypervisor, etc with -S <hypervisor> options. For example, we will using cloud-hypervisor as a default hypervisor for Kata Containers

./kata-manager.sh -S clh

You can follow this post or official document of Kata Containers here for any details.

2. Docker Installation ( Optional )

If you install Kata Containers with Docker by using kata-manager.sh you can skip this step. Follow this guide if you only install Kata Containers without Docker in step 1.

3. Kolla-Ansible Preparation

Deploying OpenStack with Kolla-Ansible is quite simple. For this case, We will using OpenStack Dalmatian ( 2024.2 ).

Install python build dependencies

sudo apt install git python3-dev libffi-dev gcc libssl-dev libdbus-glib-1-dev

Create python virtual env

Create python virtual env for Kolla

python3 -m venv /path/to/venv

Activate the virtual env

source /path/to/venv/bin/activate

Install pip Install pip and make sure we using the latest version of pip

pip install -U pip

Install Ansible

pip install 'ansible-core>=2.17,<2.17.99'

Install Kolla-Ansible

Install Kolla-Ansible and its dependencies using pip

pip install git+https://opendev.org/openstack/kolla-ansible@stable/2024.2

Create Kolla directory

Create directory for kolla config and make sure the permission is accessible with user.

sudo mkdir -p /etc/kolla
sudo chown $USER:$USER /etc/kolla

Copy preparation file

cp -r /path/to/venv/share/kolla-ansible/etc_examples/kolla/* /etc/kolla

Copy inventory file

cp /path/to/venv/share/kolla-ansible/ansible/inventory/all-in-one .

Install Kolla dependencies

kolla-ansible install-deps

Generate passwords

kolla-genpwd

Edit globals.yml

Edit globals.yml file and make sure zun are enabled.

enable_zun: "yes"
enable_kuryr: "yes"
enable_etcd: "yes"
docker_configure_for_zun: "yes"
containerd_configure_for_zun: "yes"

You can also include another OpenStack service to install based on your needs.

Bootstrap server

kolla-ansible bootstrap-servers -i all-in-one

4. Add Kata Runtime

After bootstraping server, we need some configuration in Docker and Containerd side before deploy OpenStack. Change file /etc/docker/daemon.json with this line below

{
    "bridge": "none",
    "ip-forward": false,
    "iptables": false,
    "log-opts": {
        "max-file": "5",
        "max-size": "50m"
    },
    "runtimes": {
        "kata": {
            "runtimeType": "io.containerd.kata.v2",
            "options": {}
        }
    }
}

This means we registered kata runtime in Docker configuration. After that, dump all containerd configuration and place it into /etc/containered/config.toml.

containerd config dump | tee /etc/containerd/config.toml

Edit file /etc/containerd/config.toml to do some changes. in [grpc] section, edit gid options

...
[grpc]
gid = 42463
...

Save the configuration. Now, restart containerd and docker service

systemctl restart containerd docker

5. Deploy OpenStack

After all completed, do prechecks before deploy OpenStack

kolla-ansible prechecks -i all-in-one

If no errors shown, we can deploy OpenStack

kolla-ansible deploy -i all-in-one

Wait until OpenStack are successfully deployed.

6. Launch a Container

Access the OpenStack Horizon Dashboard and then create network, subnet, ssh keypair, security group. We need all of these components to create container. Move to menu Container to begin create a container.

Choose Create Container. Then, input the information about the container. For example, we will create nginx container like this picture below.

Then, input the container spesification. Don't forget to use kata as a runtime like this picture below.

Fill another requirements like network, volume if you need persistent volume, and other options. Choose create and wait until container created like this picture below.

Conclusions

Integrating Kata Containers as a runtime for OpenStack Zun adds a valuable layer of security and workload isolation to containerized environments. By leveraging lightweight virtual machines, Kata provides strong boundaries between workloads—making it ideal for multi-tenant or untrusted scenarios often found in cloud platforms. This setup allows OpenStack users to benefit from the flexibility of containers without compromising on isolation, all while maintaining compatibility with existing OpenStack services. As container technologies continue to evolve, combining Zun and Kata offers a future-proof, security-conscious approach to running containers at scale within OpenStack.

Deploy Kata Containers in Ubuntu 24.04

Kiki Fachry — Sun, 06 Apr 2025 10:55:15 +0000

In previous post, we’ve explored the core differences between traditional containers and Kata Containers. In this post we will start to install kata containers. Installing Kata Containers isn’t overly complex—and once set up. It can integrate seamlessly with container runtimes like containerd or CRI-O, and even work inside Kubernetes clusters. We will post it later but in this section, I’ll walk you through how to install Kata Containers on an Ubuntu system, step by step, so you can try it out yourself and see the isolation in action.

Kata Containers can be installed with 3 methods :

Official distro packages
Automatic
Using kata-deploy ( for running kubernetes )

Recommended way to install Kata Containers is using official distro packages. But unfortunately, Kata Containers doesn't support debian-based packages, so we will install using automatic methods. With this method, we will use kata-manager script to automate installation.

Prerequisites

Before we begin, we need Ubuntu 24.04 baremetal host or VM with nested virtualization. Kata Containers rely on hardware virtualization to provide the strong isolation that sets them apart from traditional containers. This means each Kata container runs inside its own lightweight virtual machine. So, if you're running Kata Containers inside a virtual machine (like on a public cloud or a development VM), you'll need to enable nested virtualization—a feature that allows a VM to create and manage other VMs. Without it, the underlying hypervisor (like QEMU or Cloud Hypervisor) used by Kata won't be able to launch the isolated guest kernel, and the container runtime will fail to start Kata-based workloads. For example, if you use VMware vSphere you can enable Hardware Assisted Virtualization and IOMMU like this picture below:

Installation

Login to your Ubuntu host with SSH
Update repositoriy and upgrade the Ubuntu system

sudo apt-get update && sudo apt-get upgrade -y

Reboot the host. Wait until the host powered on and we can do SSH again
Download kata-manager script

wget https://raw.githubusercontent.com/kata-containers/kata-containers/main/utils/kata-manager.sh

Make the script executable

chmod +x kata-manager.sh

Execute the script to install Kata Containers with Containerd.

./kata-manager.sh

You can add -h for any command help and customization. For example, if we only install Kata Containers we need to add -o options :

./kata-manager.sh -o

Also. if we want to install with Docker we need to add -D options :

./kata-manager.sh -D

Installation progress will begin. After the installation completed, check the installed services

./kata-manager.sh -l

Make sure Kata Containers and Containerd was installed

INFO: Getting version details
INFO: Kata Containers: installed version: Kata Containers containerd shim (Golang): id: "io.containerd.kata.v2", version: 3.15.0, commit: c0632f847fe706090d64951ba6b68865a416bdb4
INFO: Kata Containers: latest version: 3.15.0

INFO: containerd: installed version: containerd github.com/containerd/containerd v1.7.27 05044ec0a9a75232cad458027ca83437aae3f4da
INFO: containerd: latest version: v2.0.4

INFO: Docker (moby): installed version: <not installed>
INFO: Docker (moby): latest version: v28.0.4

Testing

After installation completed, we will test the Kata Containers with deploying a container and see the isolation is working.

Run uname -a to make sure the host OS kernel version

root@dev-master:~# uname -a
Linux dev-master 6.8.0-57-generic #59-Ubuntu SMP PREEMPT_DYNAMIC Sat Mar 15 17:40:59 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
root@dev-master:~#

We can see the host OS kernel version is 6.8

Pull some container image to deploy. For example, we will use rocky linux docker image

ctr image pull docker.io/rockylinux/rockylinux:latest

Deploy rocky linux image with defaut runtime, and run command uname -a to see what used kernel

root@dev-master:~# ctr run --rm docker.io/rockylinux/rockylinux:latest rocky-defaut uname -a
Linux dev-master 6.8.0-57-generic #59-Ubuntu SMP PREEMPT_DYNAMIC Sat Mar 15 17:40:59 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
root@dev-master:~#

From this testing, we can see the rocky-default container was using the same OS kernel from the host just like traditional container concept. Now, deploy rocky linux image with Kata runtime

root@dev-master:~# ctr run --runtime io.containerd.kata.v2 --rm docker.io/rockylinux/rockylinux:latest rocky-kata uname -a
Linux localhost 6.12.13 #1 SMP Thu Mar 13 11:34:50 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
root@dev-master:~#

Conclusions

When a container is run using the default runtime, it shares the host's kernel. This means if you check the kernel version from inside the container (using uname -a), you'll see the same version as your host operating system. In contrast, when you run a container using Kata Containers, the process runs inside a lightweight virtual machine with its own dedicated kernel. Running uname -a will return a different kernel version, typically the one shipped by Kata itself. This is a simple but powerful way to confirm that Kata is using hardware virtualization to isolate your container workloads—each one gets its own kernel, separate from the host.

Kata Containers: Lightweight VMs for Containers

Kiki Fachry — Sun, 06 Apr 2025 07:54:26 +0000

Introduction

In today’s cloud-native world, containers have become the standard unit of software delivery. They allow developers to package applications along with their dependencies into lightweight, portable units that can run reliably across different environments. This has revolutionized the way we build, ship, and run applications—from developer laptops to large-scale Kubernetes clusters.

But while containers are efficient and fast, they come with a trade-off: security. Traditional containers share the host operating system’s kernel. That means if a container is compromised, there’s a potential risk to the entire system. For many teams running multi-tenant clusters or handling untrusted workloads, that risk isn’t acceptable.

This is where Kata Containers come in—a project designed to bridge the gap between the speed of containers and the strong isolation of virtual machines. Kata Containers look and feel like containers, but under the hood, they run inside lightweight VMs using a separate kernel. This offers a level of isolation closer to traditional virtualization, without the overhead that comes with full-blown hypervisors. Whether you're managing sensitive data, running sandboxed workloads, or building a secure Kubernetes platform, Kata Containers can offer a powerful middle ground.

To better understand what makes Kata Containers different, let’s take a look at a side-by-side comparison with traditional containers.

source : https://yqintl.alicdn.com/fb67232d2a5e2e8afbc7968c9227f7dd4121bbaf.png

On the right side of the diagram, we see how traditional containers work. Each containerized process (A, B, C) shares the same Linux kernel. Isolation is achieved using namespaces, cgroups, and additional filters like seccomp, MAC (Mandatory Access Control), and capabilities. While this method is lightweight and fast, it still means that all containers rely on the host’s kernel. If one container exploits a kernel vulnerability, it could potentially affect others or even the host.

On the left side, Kata Containers take a different approach. Each containerized process runs inside its own lightweight virtual machine, with a dedicated kernel (e.g., Linux Kernel A, B, C). These VMs are powered by hardware virtualization, which provides strong, hardware-enforced isolation between workloads. From the perspective of the process inside, it’s still running in a container—but behind the scenes, it’s isolated as if it were a small, independent VM.

In practice, this means Kata Containers offer much stronger security boundaries. If a container running inside a Kata VM is compromised, the attack surface is significantly reduced—it would have to break through an entire virtualized layer rather than just a namespace.

The tradeoff? Slightly more overhead compared to traditional containers. But in environments where security and workload isolation are top priorities—like multi-tenant platforms, confidential workloads, or untrusted code—Kata Containers strike a compelling balance between performance and protection.

Kata Containers may not be the default choice for every workload, but when security and strong isolation matter just as much as performance, they offer a powerful and elegant solution that bridges the best of both containers and virtual machines.

Resources

https://github.com/kata-containers/kata-containers/tree/main/docs/install