Kata 架构

Posted 2021-01-04 clisa

原文：https://github.com/kata-containers/documentation/blob/master/architecture.md

（欢迎纠错）

Kata-runtime

1. kata-runtime 兼容OCI spec，因此无缝衔接 Docker Engine pluggable runtime 架构。

2. kata-runtime 也通过 CRI-O 和 Containerd CRI Plugin实现 支持 Kubernetes CRI (Container Runtime Interface)。

3. kata-runtime 为每个 container (由 Docker Engine 创建) 或 pod (由 kubelet 创建) 创建 QEMU/KVM 虚拟机。

4. container 进程由 agent 创建， agent 进程运行在 VM 内部作为 deamon。

5. kata-agent 使用一个 virtio 串口接口在 guest 中运行一个 gRPC 服务，该接口在主机上暴露为一个串口设备。

6. kata-runtime 使用 gRPC协议与agent通信。 ----该协议允许 runtime 发送 container 管理命令到 agent；也用于在 guest 与 Docker Engine 之间传递 I/O 流。

7. 对于任何给定的 container， init 进程和所有在容器内部潜在执行的命令，以及他们相关的 I/O 流，都需要由 QEMU 通过 virtio 串口接口导出。每个 VM 启动一个 kata-proxy 来处理这些命令和流的多路复用。

8. 在主机上，每个 container 进程的移除由 container 栈上层的一个 reaper 完成。在 Docker 情况下，是 containerd-shim；在 CRI-O下是 common。当kata-container 进程运行在它们自己的VM内部时， reaper不能监控、控制、回收它们。 kata-runtime 通过在 reaper 和 kata-proxy 之间创建一个附加的 shim进程(kata-shim) 来解决这个问题。 kata-shim 实体既将信号和 stdin 流转发到 guest 上的 container 进程，也通过 reaper 将 container 的 stdout 与 stderr 流传回到 CRI shim 或 docker。

 

Hypervisor

1. kata

 

Agent

1. kata-agent 是一个运行在 guest 中作为超级管理员用来管理容器和容器中进程的进程。

2. kata-agent 的执行单元是 sandox。 kata-agent sandbox 是一组命名空间 (NS, UTS, IPC, PID) 定义的容器sandbox。kata-runtime 可以在一个 VM 中运行多个容器用于支持那些要求一个 pod 运行多个容器的容器引擎。在 docker 情况下， 一个 pod 一个容器。

3. kata-agent 与 kata 组件之间通过 gRPC 通信。 它也运行一个 yamux 服务器在同一个 gRPC URL上。

4. kata-agent 利用 libcontainer 管理容器的生命周期。与 runc 大量复用代码。

 

Proxy

1. 同VM 通信由 virtio-serial 或 vsock(host kernel > 4.8) 实现。

2. VM 可能运行了多个容器进程。当使用 virtio-serial 时，每个进程相关的 I/O 流需要多路复用。使用 vsock 则无需此组件。

3. kata-proxy 是一个提供 kata-agent 到 kata-shim 和 VM相关的 kata-runtime 的访问的进程 。它的主要角色是在每个 kata-shim 实体与 kata agent之间路由 I/O 流与信号。 kata-proxy 通过一个unix domain socket 连上 kata-agent，这个socket 由 kata-runtime 在启动 kata-agent 时提供。kata-proxy 使用 yamux 来 multiplex gRPC请求到与kata-agent的连接。

 

----未完待续----