Are you feeling adventurous today? Good, so let’s give a try to some
of the coolest upcoming technologies.
-
podman is a tool for
managing containers. If you’re familiar with docker, you’ll find
it’s CLI quite similar. RHEL8 will include podman as part of the
container-tools module.
-
Kata Containers is an OCI
Runtime which runs
containerized processes inside a VM, using QEMU+KVM. This gives
you the versatility of containers, with the isolation of a VM, among
other nice features like static resource management and PCI
passthru. Kata is not included nor supported by RHEL8, but I hope
it’ll eventually make into some minor release.
-
RHEL8 Beta
is… well, if you’re reading this, I’m pretty sure you already know
what RHEL8 is ;-)
Prerequisites
I assume you already have installed RHEL8 Beta bare metal or inside
a VM. In case of the later, make sure you have nested virtualization
enabled in your Host, and virtualization extensions are available in
the VM.
As we’re going to need to download some packages, make sure you’ve
registered the system and attached it to a pool using
subscription-manager. A developer or evaluation subscription should
be enough.
Getting your hands dirt
First, we’re going to install the container-tools module, which
includes everything we need to start running containers in RHEL8.
1
|
sudo yum module install container-tools
|
As Kata Containers is not yet available in RHEL8, I’ve created a
repo so you don’t need to build it from sources. There are basically
the same RPMs available in Kata’s OBS service for Fedora 28, except
for kata-runtime, which I rebuilt to make it play nice with RHEL8
dependencies.
Let’s add this repository to the yum config. Create the file
/etc/yum.repos.d/kata.repo, and drop in something like this:
1
2
3
4
5
|
[kata-rhel8]
name = Kata Containers for RHEL8
baseurl = https://repo.sinrega.org/kata-rhel8
enabled = 1
gpgcheck = 0
|
Now we’re going to install kata-runtime, which will grab the rest of
the packages as a dependency:
1
|
sudo yum install kata-runtime
|
We’re almost there. We just need to instruct podman to use
kata-runtime as the OCI Runtime. To do this, we need to override
some libpod (podman’s underlying library) defaults:
1
|
sudo cp /usr/share/containers/libpod.conf /etc/containers/libpod.conf
|
Now let’s edit /etc/containers/libpod.conf, and add
/usr/bin/kata-runtime at the beginning of the runtime-path list. It
should end looking like this:
1
2
3
4
5
6
7
8
9
|
# Paths to look for a valid OCI runtime (runc, runv, etc)
runtime_path = [
"/usr/bin/kata-runtime",
"/usr/bin/runc",
"/usr/sbin/runc",
"/sbin/runc",
"/bin/runc",
"/usr/lib/cri-o-runc/sbin/runc"
]
|
We also need to disable SELinux labeling, as Kata Containers still
doesn’t support it. Someone may argue that this isn’t needed as Kata
uses a different security model, but I think Kata should consider
adding support for it (an additional security layer never
hurts ;-).
For the moment, go to the end of /etc/containers/libpod.conf,
uncomment the label option and set it to false. It should look
like this:
1
2
|
# Default libpod support for container labeling
label=false
|
Running your first virtualized container
OK, we’re ready for running our first virtualized container. And we’re
going to do it in exactly the same way we would run a conventional
container:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
[slp@kata ~]$ sudo podman run -ti --rm fedora /bin/bash
Trying to pull registry.redhat.io/fedora:latest...Failed
Trying to pull quay.io/fedora:latest...Failed
Trying to pull docker.io/fedora:latest...Getting image source signatures
Copying blob sha256:d0483bd5a55488f5ba6383a5cc8553d5101864f03acd07eabc5df7563c3692cf
83.23 MB / 83.23 MB [======================================================] 4s
Copying config sha256:8c568f1043264e34f0a8774587266565c7e5e54e9ea6b97ab459086d18ac5175
2.29 KB / 2.29 KB [========================================================] 0s
Writing manifest to image destination
Storing signatures
[root@023baa97456d /]# uname -a
Linux 023baa97456d 4.14.67-10.1.container #1 SMP Fri Sep 28 02:53:22 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
[root@023baa97456d /]# id
uid=0(root) gid=0(root) groups=0(root)
[root@023baa97456d /]#
|
So, how do we know we’re using Kata? Let’s switch to another terminal
or ssh session and search for the container’s ID in the process list:
1
2
3
4
5
|
[slp@kata ~]$ ps -ef | grep 023baa97456d
root 2172 1 0 08:19 ? 00:00:00 /usr/libexec/podman/conmon -s -c 023baa97456d4cf2eefd3619f81c557adb19cd3226fa29106608fe73e7b2843f -u 023baa97456d4cf2eefd3619f81c557adb19cd3226fa29106608fe73e7b2843f -r /usr/bin/kata-runtime -b /var/lib/containers/storage/overlay-containers/023baa97456d4cf2eefd3619f81c557adb19cd3226fa29106608fe73e7b2843f/userdata -p /var/run/containers/storage/overlay-containers/023baa97456d4cf2eefd3619f81c557adb19cd3226fa29106608fe73e7b2843f/userdata/pidfile -l /var/lib/containers/storage/overlay-containers/023baa97456d4cf2eefd3619f81c557adb19cd3226fa29106608fe73e7b2843f/userdata/ctr.log --exit-dir /var/run/libpod/exits --socket-dir-path /var/run/libpod/socket -t --log-level error
root 2185 2172 3 08:19 ? 00:00:04 /usr/bin/qemu-lite-system-x86_64 -name sandbox-023baa97456d4cf2eefd3619f81c557adb19cd3226fa29106608fe73e7b2843f -uuid 9f6fcd38-4d7a-49a1-8ead-0a2b5a3f111b -machine pc,accel=kvm,kernel_irqchip,nvdimm -cpu host,pmu=off -qmp unix:/run/vc/vm/023baa97456d4cf2eefd3619f81c557adb19cd3226fa29106608fe73e7b2843f/qmp.sock,server,nowait -m 2048M,slots=10,maxmem=4804M -device pci-bridge,bus=pci.0,id=pci-bridge-0,chassis_nr=1,shpc=on,addr=2 -device virtio-serial-pci,disable-modern=true,id=serial0 -device virtconsole,chardev=charconsole0,id=console0 -chardev socket,id=charconsole0,path=/run/vc/vm/023baa97456d4cf2eefd3619f81c557adb19cd3226fa29106608fe73e7b2843f/console.sock,server,nowait -device nvdimm,id=nv0,memdev=mem0 -object memory-backend-file,id=mem0,mem-path=/usr/share/kata-containers/kata-containers-image_clearlinux_1.3.0_agent_042c3ebd71c.img,size=536870912 -device virtio-scsi-pci,id=scsi0,disable-modern=true -object rng-random,id=rng0,filename=/dev/urandom -device virtio-rng,rng=rng0 -device virtserialport,chardev=charch0,id=channel0,name=agent.channel.0 -chardev socket,id=charch0,path=/run/vc/vm/023baa97456d4cf2eefd3619f81c557adb19cd3226fa29106608fe73e7b2843f/kata.sock,server,nowait -device virtio-9p-pci,disable-modern=true,fsdev=extra-9p-kataShared,mount_tag=kataShared -fsdev local,id=extra-9p-kataShared,path=/run/kata-containers/shared/sandboxes/023baa97456d4cf2eefd3619f81c557adb19cd3226fa29106608fe73e7b2843f,security_model=none -netdev tap,id=network-0,vhost=on,vhostfds=3,fds=4 -device driver=virtio-net-pci,netdev=network-0,mac=9e:c1:3c:95:e2:5f,disable-modern=true,mq=on,vectors=4 -global kvm-pit.lost_tick_policy=discard -vga none -no-user-config -nodefaults -nographic -daemonize -kernel /usr/share/kata-containers/vmlinuz-4.14.67.12-10.1.container -append tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k console=hvc0 console=hvc1 iommu=off cryptomgr.notests net.ifnames=0 pci=lastbus=0 root=/dev/pmem0p1 rootflags=dax,data=ordered,errors=remount-ro rw rootfstype=ext4 quiet systemd.show_status=false panic=1 nr_cpus=4 init=/usr/lib/systemd/systemd systemd.unit=kata-containers.target systemd.mask=systemd-networkd.service systemd.mask=systemd-networkd.socket -smp 1,cores=1,threads=1,sockets=1,maxcpus=4
root 2192 2172 0 08:19 ? 00:00:00 /usr/libexec/kata-containers/kata-proxy -listen-socket unix:///run/vc/sbs/023baa97456d4cf2eefd3619f81c557adb19cd3226fa29106608fe73e7b2843f/proxy.sock -mux-socket /run/vc/vm/023baa97456d4cf2eefd3619f81c557adb19cd3226fa29106608fe73e7b2843f/kata.sock -sandbox 023baa97456d4cf2eefd3619f81c557adb19cd3226fa29106608fe73e7b2843f
root 2206 2172 0 08:19 pts/1 00:00:00 /usr/libexec/kata-containers/kata-shim -agent unix:///run/vc/sbs/023baa97456d4cf2eefd3619f81c557adb19cd3226fa29106608fe73e7b2843f/proxy.sock -container 023baa97456d4cf2eefd3619f81c557adb19cd3226fa29106608fe73e7b2843f -exec-id 023baa97456d4cf2eefd3619f81c557adb19cd3226fa29106608fe73e7b2843f -terminal
|
Here we have podman’s conmon, Kata’s kata-proxy and kata-shim,
and… a QEMU instance!
Yes, this container is running in a fully-fledged VM, which started
almost instantly. In fact, on my test machine (which is a VM, so I’m
using nested virtualization), starting a container with runc (the
standard OCI runtime) takes about 1.3 seconds, while doing it with
Kata takes 3.2 seconds:
1
2
3
4
5
6
7
8
9
10
11
12
|
[slp@kata ~]$ time sudo podman run -ti --rm fedora /bin/false
real 0m3.243s
user 0m0.193s
sys 0m0.300s
[slp@kata ~]$ sudo vi /etc/containers/libpod.conf
(comment out the kata-runtime line)
[slp@kata ~]$ time sudo podman run -ti --rm fedora /bin/false
real 0m1.355s
user 0m0.238s
sys 0m0.368s
|
While it still needs to evolve a bit, Kata Containers is a promising
technology combining container’s flexibility with VM’s isolation,
which can be very interesting specially for running untrusted
workloads, or for NFV (thanks to the possibility of using PCI passthru
and SRIOV).
If you found this post interesting, please consider dropping me a line
on Mastodon (@slp@mstdn.io) or Twitter
(@slp1605). If I get some positive
feedback, I’ll write a part 2, talking about Kata’s inner workings.