This repository has been archived by the owner on May 12, 2021. It is now read-only.
Kata images
nitkon edited this page Aug 26, 2019
·
14 revisions
- Comparing Rootfs images with initrd images
- Why images use an init daemon
- systemd as the image init daemon
- Long term solution
- References
This page provides information on Kata Containers "mini O/S" images.
| Image type | init | Boot speed | Image Size | Config option | Notes |
|---|---|---|---|---|---|
| rootfs | systemd | good | small | image= |
Flexible as easy to customise. |
| rootfs | agent | faster | small | n/a | No advantage over using initrd=. |
| initrd | agent | fastest | smallest | initrd= |
Not flexible - users cannot just add an extra service to a custom image. All extra functionality needs to be provided by the agent ("re-inventing the wheel"). |
| initrd | systemd | n/a | n/a | - | No advantage over using image=. |
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 | yes | Uses kata-journald-host-redirect.service. |
| Debug console | yes | yes | yes | Would require the agent as init to handle spawning a shell, etc. |
| Factory | no | no | yes | |
| Guest time sync | yes | yes | no | Uses chrony. Plan to introduce a gRPC feature for the initrd scenario. |
| Start agent | "yes" but easy to change | yes | yes |
kata-agent is the init daemon in an initrd image. |
| Static tracing | yes | yes | no | Currently relies on kata-agent.service to shutdown VM. Could modify agent to replace the shutdown code in the service though. |
- Ability to manage services.
- Allows users to add additional services to custom images.
- 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 Examples: use systemd modules-load to load out-of-tree drivers that are installed on the rootfs.
- 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.
- 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
- For maintenance purposes it would be better reduce the testing matrix with just one or 2 variants of the images (all using agent or systemd as agent)
- Launch in kernel terminal a program or logs (
tty=Stty0): Launch a bash session for debug or logs for proxy - Redirect agent logs using vsocks: Use case or opentracing
- Allow launch additional binaries (service like): Use case launch chrony
- 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
As part of Kata Containers project simplification we should evaluate how to reduce the kata complexity and this is a key point. By providing a de facto image solution will help for:
- Easier testing with only one rootfs flavor (talking about agent as init or not)
- Easy to use for end users, instead of bring a lot of documentation to users about what image use depending its use cases just provide only working solution. This will be a benefit too when OS provides take kata, instead of let them pick one image variant (that later a user may need to change and build manually).