Kata images

• Comparing Rootfs images with initrd images
• Why images use an init daemon
• systemd as the image init daemon
  • pros
  • cons

This page provides information on Kata Containers "mini O/S" images.

Comparing Rootfs images with initrd images

Comparison of running Kata with a image= entry with running Kata with an initrd= entry in the configuration.toml configuration file.

Feature	systemd-specific	Available in image	Available in initrd	Notes
Agent log messages with use_vsock=true	yes	yes	no	Uses kata-journald-host-redirect.service.
Debug console	yes	yes	no
Guest time sync	yes	yes	no	Uses chrony.
Static tracing	yes	yes	no	Currently relies on kata-agent.service to shutdown VM.
Start agent	"yes" but easy to change	yes	yes	kata-agent is the init daemon in an initrd image.

Why images use an init daemon

• Ability to manage services.
• Allows users to add additional services to custom images.

systemd as the image init daemon

pros

• De facto Linux init daemon.
• Avoids having to "re-invent the wheel" by implementing additional functionality in the agent - just drop in a standard service, otherwise the logic has to be implemented on the agent
• Automatically handles mounting standard mounts (/dev, etc) (agent as init already handle it as well)
• Leverage systemd boot time performance improvements from Clear Linux.
• Allows underlying osbuilder distro to be changed with minimal impact on the environment.

cons

• Large binary - bloats image.
• Large potential attack surface.
  • Image needs to be updated not only with agent related changes but also to fix Systemd CVEs
• Sometimes from upgrades of systemd break use cases
• Possible slower boot time as systemd has to start first and its services, then the kata agent is started

Features missing with agent as init from systemd

• Launch a terminal to allow run a debug console
• Redirect agent logs using vsocks (for opentracing support)
• Allow launch additional binaries (service like)

Other binaries that kata needs inside the guest

• iptables: used by kata agent to setup iptables rules inside the guest, it uses the iptables provided by the os guest.
• chrony: Synchronize guest clock with host