Project: Kata Containers (Runtime / Container Runtime)
File: guest-assets.md

Kata Containers creates a VM in which to run one or more containers. It does this by launching a to create the VM. The hypervisor needs two assets for this task: a Linux kernel and a small root filesystem image to boot the VM. The is passed to the hypervisor and used to boot the VM. The default kernel provided in Kata Containers is highly optimized for kernel boot time and minimal memory footprint, providing only those services required by a container workload. It is based on the latest Linux LTS (Long Term Support) . The hypervisor uses an image file which provides a minimal root filesystem used by the guest kernel to boot the VM and host the Kata Container. Kata Containers supports both initrd and rootfs based minimal guest images. The provide both an image and an initrd, both of which are created using the tool. Notes: Although initrd and rootfs based images are supported, not all support both types of image. The guest image is unrelated to the image used in a container workload. For example, if a user creates a container that runs a shell in a BusyBox image, they will run that shell in a BusyBox environment. However, the guest image running inside the VM that is used to host that BusyBox image could be running Clear Linux, Ubuntu, Fedora or any other distribution potentially. The `osbuilder` tool provides which can be built into either initrd or rootfs guest images. If you are using a [packaged version of Kata Containers](../../install), you can see image details by running the script as `root` and looking at the "Image details" section of the output. The default packaged rootfs image, sometimes referred to as the _mini O/S_, is a highly optimized container bootstrap system. If this image type is , when the user runs the : The will launch the configured . The hypervisor will boot the mini-OS image using the . The kernel will start the init daemon as PID 1 (`systemd`) inside the VM root environment. `systemd`, running inside the mini-OS context, will launch the in the root context of the VM. The agent will create a new container environment, setting its root filesystem to that requested by the user (Ubuntu in ). The agent will then execute the command (`sh(1)` in ) inside the new

The table below summarises the default mini O/S showing the environments that are created, the services running in those environments (for all platforms) and the root filesystem used by each service: | Process | Environment | systemd service? | rootfs | User accessible | Notes | |-|-|-|-|-|-| | systemd | VM root | n/a | | | The init daemon, running as PID 1 | | | VM root | yes | | | Runs as a systemd service | | `chronyd` | VM root | yes | | | Used to synchronise the time with the host | | container workload (`sh(1)` in ) | VM container | no | User specified (Ubuntu in ) | | Managed by the agent | See also the . Notes: The "User accessible" column shows how an administrator can access the environment. The container workload is running inside a full container environment which itself is running within a VM environment. See the for details of the default distribution for platforms other than Intel x86_64. The initrd image is a compressed `cpio(1)` archive, created from a rootfs which is loaded into memory and used as part of the Linux startup process. During startup, the kernel unpacks it into a special instance of a `tmpfs` mount that becomes the initial root filesystem. If this image type is , when the user runs the : The will launch the configured . The hypervisor will boot the mini-OS image using the . The kernel will start the init daemon as PID 1 (the ) inside the VM root environment. The will create a new container environment, setting its root filesystem to that requested by the user (`ubuntu` in ). The agent will then execute the command (`sh(1)` in ) inside the new container. The table below summarises the default mini O/S showing the environments that are created, the processes running in those environments (for all platforms) and the root filesystem used by each service: | Process | Environment | rootfs | User accessible | Notes | |-|-|-|-|-| | | VM root | | | Runs as the init daemon (PID 1) | | container workload | VM container | User specified (Ubuntu in this example) | | Managed by the agent | Notes: The "User accessible" column shows how an administrator can access the environment. It is possible to use a standard init daemon such as systemd with an initrd image if this is desirable. See also the . | Image type | Default distro | Init daemon | Reason | Notes | |-|-|-|-|-| | | (for x86_64 systems)| systemd | Minimal and highly optimized | systemd offers flexibility | | | | Kata (as no systemd support) | Security hardened and tiny C library | See also: The tool This is used to build all default image types. The The `default-image-name` and `default-initrd-name` options specify the default distributions for each image type.