8i | 9i | 10g | 11g | 12c | 13c | 18c | 19c | 21c | 23ai | Misc | PL/SQL | SQL | RAC | WebLogic | Linux

Home » Articles » Linux » Here

Kata Containers : Running Containers Inside Lightweight Virtual Machines on Oracle Linux 7 (OL7)

This article describes how to configure Kata Containers on Oracle Linux 7 (OL7), allowing you to run containers inside lightweight virtual machines (VMs).

Related articles.

Introduction

In my article called An Oracle DBA's Guide to Docker there is a section called Virtual Machines vs Containers, which compares the pros and cons of virtual machines and containers. One of the advantages of containers is the reduced overhead, as they share the kernel with the host operating system, but this is also a disadvantage as it means they have less isolation.

Kata Containers allow you to have the isolation of a virtual machine for each container, whilst retaining the feel and life cycle of a container. By adding the kata-runtime to your Docker installation, you allow Docker run commands to automatically create a lightweight virtual machine, with the container running inside it. The virtual machine is created and managed using KVM and QEMU, and uses a stripped back OS image, to keep things as lean and quick as possible.

At this point you are probably thinking you don't want to add a hypervisor into the mix, but in reality most cloud container solutions are based on virtual machines anyway, so it is likely there is already I hypervisor in the mix, even if it is not visible to you.

Assumptions

There are some assumptions you need to consider when working through this article.

Installation

Enable the ol7_kvm_utils repository and install the qemu package.

yum-config-manager --enable ol7_kvm_utils
yum install -y qemu

Enable the oracle-olcne-release-el7 repository and install the kata-runtime package.

yum install -y oracle-olcne-release-el7
yum install -y kata-runtime

If you already have Docker installed, as described here, you can ignore the next step. If not, this is a quick and dirty setup to get it working.

yum install -y docker-engine
systemctl enable docker
systemctl start docker

Configuration

We have to make the kata-runtime available to the Docker engine. The most reliable way to do that is to add the runtime into the "/etc/docker/daemon.json" file. Depending on how you installed Docker, and what subsequent configuration you have, the contents of the file may look different, so we'll present several variations.

If you did the quick and dirty Docker installation, the "/etc/docker/daemon.json" file will not exist, so you can create it with the following contents.

{
    "default-runtime": "runc",
    "runtimes": {
         "kata-runtime": {
             "path": "/usr/bin/kata-runtime"
         }
    }
}

We have left the default runtime as "runc", but have added an additional runtime called "kata-runtime".

If you did the installation described here, you will already have a "/etc/docker/daemon.json" file containing a reference to the BTRFS storage driver. In that case, add runtime config to the existing file, so it looks like the following, with the runtime additions in bold.

{
    "storage-driver": "btrfs",
    "default-runtime": "runc",
    "runtimes": {
         "kata-runtime": {
             "path": "/usr/bin/kata-runtime"
         }
    }
}

If you have the experimental features enabled, your current file may already contain a reference for that, in which case the edited file will look like the following, with the runtime additions in bold.

{
    "storage-driver": "btrfs",
    "experimental": true,
    "default-runtime": "runc",
    "runtimes": {
         "kata-runtime": {
             "path": "/usr/bin/kata-runtime"
         }
    }
}

Once the "/etc/docker/daemon.json" file has been amended, you will need to restart Docker.

systemctl daemon-reload
systemctl restart docker

We can see the runtime is now available using the docker info command.

# docker info
Client:
 Debug Mode: false

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 1
 Server Version: 19.03.1-ol
 Storage Driver: devicemapper
  Pool Name: docker-249:1-870247-pool
  Pool Blocksize: 65.54kB
  Base Device Size: 10.74GB
  Backing Filesystem: xfs
  Udev Sync Supported: true
  Data file: /dev/loop0
  Metadata file: /dev/loop1
  Data loop file: /var/lib/docker/devicemapper/devicemapper/data
  Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
  Data Space Used: 152MB
  Data Space Total: 107.4GB
  Data Space Available: 107.2GB
  Metadata Space Used: 643.1kB
  Metadata Space Total: 2.147GB
  Metadata Space Available: 2.147GB
  Thin Pool Minimum Free Space: 10.74GB
  Deferred Removal Enabled: true
  Deferred Deletion Enabled: true
  Deferred Deleted Device Count: 0
  Library Version: 1.02.158-RHEL7 (2019-05-13)
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: kata-runtime runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version:
 runc version:
 init version: fec3683
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 4.1.12-124.37.1.el7uek.x86_64
 Operating System: Oracle Linux Server 7.7
 OSType: linux
 Architecture: x86_64
 CPUs: 16
 Total Memory: 23.23GiB
 Name: homer.localdomain
 ID: MMEA:IKYO:SS7A:SEK5:VEOD:GRTV:HLAA:BCTY:EC4M:5Z5P:JBO4:6EOZ
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: the devicemapper storage-driver is deprecated, and will be removed in a future release.
WARNING: devicemapper: usage of loopback devices is strongly discouraged for production use.
         Use `--storage-opt dm.thinpooldev` to specify a custom block storage device.
Registries:
#

It's worth noting, some instructions suggest you can add the runtime using the following setting in the "/etc/sysconfig/docker" file.

OPTIONS='-D --add-runtime kata-runtime=/usr/bin/kata-runtime'

Some versions of the Docker engine will pick up these settings and some will not. The recommendations in the Oracle Linux documentation are to make changes in the "/etc/docker/daemon.json" files and avoid using the "/etc/sysconfig/docker" file.

Testing

We check the kernel version of our host machine.

# uname -r
4.1.12-124.37.1.el7uek.x86_64
#

We run a container using the "oraclelinux:7-slim" image and check the kernel version inside the container. Since Docker uses the host kernel, we get the same kernel version returned. Remember, we have not altered the default action of Docker. We've just made a new runtime available.

# docker run --rm oraclelinux:7-slim uname -r
4.1.12-124.37.1.el7uek.x86_64
#

We repeat that test, but include the --runtime=kata-runtime flag, which means the container will be started using the kata-runtime, rather than the default runtime. Now we get a different kernel version displayed.

# docker run --rm --runtime=kata-runtime oraclelinux:7-slim uname -r
4.14.35-1902.6.6.1.el7.container
#

This kernel version is the one associated with the stripped down OS inside the lightweight virtual machine, rather than the host kernel.

Issues

If you attempt to try this functionality inside an existing virtual machine, rather than on physical kit, it will all appear to be fine until you run a container, at which point you will see the following error.

# docker run --rm --runtime=kata-runtime oraclelinux:7-slim uname -r
docker: Error response from daemon: OCI runtime create failed: Could not access KVM kernel module: No such file or directory
qemu-system-x86_64: failed to initialize KVM: No such file or directory: unknown.
#

If you run the following command you will see why. Notice the last message telling you Kata Containers can't be run on this system.

# kata-runtime kata-check
INFO[0000] CPU property found                            arch=amd64 description="Intel Architecture CPU" name=GenuineIntel pid=11528 source=runtime type=attrib
ERRO[0000] CPU property not found                        arch=amd64 description="Virtualization support" name=vmx pid=11528 source=runtime type=flag
INFO[0000] CPU property found                            arch=amd64 description="64Bit CPU" name=lm pid=11528 source=runtime type=flag
INFO[0000] CPU property found                            arch=amd64 description=SSE4.1 name=sse4_1 pid=11528 source=runtime type=flag
INFO[0000] kernel property found                         arch=amd64 description="Host kernel accelerator for virtio network" name=vhost_net pid=11528 source=ru
INFO[0000] kernel property found                         arch=amd64 description="Host Support for Linux VM Sockets" name=vhost_vsock pid=11528 source=runtime t
WARN[0000] modprobe insert module failed: modprobe: ERROR: could not insert 'kvm_intel': Operation not supported
  arch=amd64 error="exit status 1" module=kvm_intel name=kata-runtime pid=11528 source=runtime
ERRO[0000] kernel property not found                     arch=amd64 description="Intel KVM" name=kvm_intel pid=11528 source=runtime type=module
INFO[0000] kernel property found                         arch=amd64 description="Kernel-based Virtual Machine" name=kvm pid=11528 source=runtime type=module
INFO[0000] kernel property found                         arch=amd64 description="Host kernel accelerator for virtio" name=vhost pid=11528 source=runtime type=m
ERRO[0000] ERROR: System is not capable of running Kata Containers  arch=amd64 name=kata-runtime pid=11528 source=runtime
ERROR: System is not capable of running Kata Containers
#

It's possible there is something you can do to make the setup possible in a virtual machine, but if in doubt, run on physical.

For more information see:

Hope this helps. Regards Tim...

Back to the Top.