-
Notifications
You must be signed in to change notification settings - Fork 299
UserGuide
** THIS DOCUMENT IS A WorkInProgress **
- Kata Containers User Guide
- Installation
- Configuration
- Appendix
This Kata Containers User Guide aims to be a comprehensive guide to the explanation of, installation, configuration, and use of Kata Containers.
The Kata Containers source repositories contain significant amounts of other documentation, covering some subjects in more detail.
Kata Containers is, as defined in the community repo:
Kata Containers is an open source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs.
It is a drop in additional OCI compatible container runtime, which can therefore be used with [Docker] and [Kubernetes].
Kata Containers is primarily a Linux based application. It can be installed on the most common Linux distributions, using the common Linux packaging tools.
Details on installation can be found in documentation repository.
For the curious, adventurous, developers or those using a distribution not presently supported with pre-built pacakges, Kata Containers can be installed from source. If you are on a distribution that is not presently supported, please feel free to reach out to the community to discuss adding support. Of course, contributions are most welcome.
Kata Containers can be installed into Docker as an additional container runtime. This does
not remove any functionality from Docker. You can choose which container runtime is the
default for Docker if none is specified. You can run Kata Container runtime containers
in parallel with other contianers using a different container runtime (such as the default
Docker runc runtime).
Instructions on how to configure Docker to add Kata Containers as a runtime can be found in the documentation repository
It should be noted, that presently Kata Containers may not function fully in all
docker compose situations. In particular, Docker compose makes use of network links to
supply its own internal DNS service, which is difficult for Kata Containers to replicate.
Work is on-going, and the Kata Containers limitations
document can be checked for the present state.
Kata Containers can be integrated as a runtime into Kubernetes. Kata Containers can be integrated via either CRI-containerd or CRI-O.
For details on configuring Kata Containers with CRI-containerd see this document
Note that pods have some different functionality from straight docker - and note them throughout the document (such as memory and cpu scaling).
Kata Containers can be used as a runtime for OpenStack by integrating with Zun. Details on how to set this integration up can be found in this document
Kata Containers has a comprehensive TOML based configuration file. Much of the information on the available configuration options is contained directly in that file. This section expands on some of the details and finer points of the configuration.
As Kata Containers runs containers inside VMs it differs from software containers in how memory is allocated and restricted to the container. VMs are allocated an amount of memory, whereas software containers can run either unconstrained (they can access, and share with other containers, all of the host memory), or they can have some constraints imposed upon them via hard or soft limits.
If no constraints are set, then Kata Containers will set the VM memory size using a combination of the value set in the runtime config file, which is 2048 MiB by default, plus the addition of the requested constraint.
Kata Containers gets the memory constraint information from the OCI JSON file passed to it by the orchestration layer. In the case of Docker, these can be set on the command line For Kubernetes, you can set up memory limits and requests
Note We should detail how limits and requests map into Kata VMs.
If the container orchestrator provides CPU constraints, then Kata Containers configures the VM per those constraints (rounded up to the nearest whole CPU), plus one extra CPU (to cater for any VM overheads). More details can be found in the cpu constraints document
Briefly explain that Kata maps in rootfs differently depending on the host side graph driver. block or 9p.
ptys, file handles, network size.
On the host, and in the container.
entropy