mirror of
https://github.com/kata-containers/kata-containers.git
synced 2026-04-03 18:43:50 +00:00
795869152d
This supersedes https://github.com/kata-containers/kata-containers/pull/12622. I replaced Zensical with mkdocs-materialx. Materialx is a fork of mkdocs-material created after mkdocs-material was put into maintenance mode. We'll use this platform until Zensical is more feature complete. Added a few of the existing docs into the site to make a more user-friendly flow. Signed-off-by: LandonTClipp <11232769+LandonTClipp@users.noreply.github.com>
95 lines
3.6 KiB
Markdown
95 lines
3.6 KiB
Markdown
# Kata Containers
|
|
|
|
Kata Containers is an open source community working to build a secure container runtime with lightweight virtual machines (VM's) that feel and perform like standard Linux containers, but provide stronger workload isolation using hardware virtualization technology as a second layer of defense.
|
|
|
|
## How it Works
|
|
|
|
Kata implements the [Open Containers Runtime Specification](https://github.com/opencontainers/runtime-spec). More specifically, it implements a containerd shim that implements the expected interface for managing container lifecycles. The default containerd runtime of `runc` spawns a container like this:
|
|
|
|
```mermaid
|
|
flowchart TD
|
|
subgraph Host
|
|
containerd
|
|
runc
|
|
process[Container Process]
|
|
containerd --> runc --> process
|
|
end
|
|
```
|
|
|
|
When containerd receives a request to spawn a container, it will pull the container image down and then call out to the runc shim (usually located at `/usr/local/bin/containerd-shim-runc-v2`). runc will then create various process isolation resources like Linux namespaces (networking, PIDs, mounts etc), seccomp filters, Linux capability reductions, and then spawn the process inside of those resources. This process runs in the host kernel.
|
|
|
|
Kata spawns containers like this:
|
|
|
|
```mermaid
|
|
flowchart TD
|
|
subgraph Host
|
|
containerdOuter[containerd]
|
|
kata
|
|
|
|
containerdOuter --> kata
|
|
kata --> kataAgent
|
|
|
|
subgraph VM
|
|
kataAgent[Kata Agent]
|
|
process[Container Process]
|
|
kataAgent --> process
|
|
end
|
|
end
|
|
```
|
|
|
|
The container process spawned inside of the VM allows us to isolate the guest kernel from the host system. This is the fundamental principle of how Kata achieves its isolation boundaries.
|
|
|
|
## Example
|
|
|
|
When Kata is installed in a system, a number of artifacts are laid down. containerd's config will be modified as such:
|
|
|
|
```toml title="/etc/containerd/config.toml"
|
|
imports = ["/opt/kata/containerd/config.d/kata-deploy.toml"]
|
|
```
|
|
|
|
This file will contain configuration for various flavors of Kata runtimes. We can see the vanilla CPU runtime config here:
|
|
|
|
```toml title="/opt/kata/containerd/config.d/kata-deploy.toml"
|
|
[plugins."io.containerd.cri.v1.runtime".containerd.runtimes.kata-qemu]
|
|
runtime_type = "io.containerd.kata-qemu.v2"
|
|
runtime_path = "/opt/kata/bin/containerd-shim-kata-v2"
|
|
privileged_without_host_devices = true
|
|
pod_annotations = ["io.katacontainers.*"]
|
|
|
|
[plugins."io.containerd.cri.v1.runtime".containerd.runtimes.kata-qemu.options]
|
|
ConfigPath = "/opt/kata/share/defaults/kata-containers/configuration-qemu.toml"
|
|
```
|
|
|
|
Because containerd's CRI is aware of the Kata runtimes, we can spawn Kubernetes pods:
|
|
|
|
```yaml
|
|
apiVersion: v1
|
|
kind: Pod
|
|
metadata:
|
|
name: test
|
|
spec:
|
|
runtimeClassName: kata-qemu
|
|
containers:
|
|
- name: test
|
|
image: "quay.io/libpod/ubuntu:latest"
|
|
command: ["/bin/bash", "-c"]
|
|
args: ["echo hello"]
|
|
```
|
|
|
|
We can also spawn a Kata container by submitting a request to containerd like so:
|
|
|
|
<div class="annotate" markdown>
|
|
|
|
```sh
|
|
$ ctr image pull quay.io/libpod/ubuntu:latest
|
|
$ ctr run --runtime "io.containerd.kata.v2" --runtime-config-path /opt/kata/share/defaults/kata-containers/configuration-qemu.toml --rm -t "quay.io/libpod/ubuntu:latest" foo sh
|
|
# echo hello
|
|
hello
|
|
```
|
|
|
|
</div>
|
|
|
|
!!! tip
|
|
|
|
`ctr` is not aware of the CRI config in `/etc/containerd/config.toml`. This is why you must specify the `--runtime-config-path`. Additionally, the `--runtime` value is converted into a specific binary name which containerd then searches for in its `PATH`. See the [containerd docs](https://github.com/containerd/containerd/blob/release/2.2/core/runtime/v2/README.md#usage) for more details.
|