原文：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 大量復用代碼。

Runtime

kata-runtime 是一個 OCI兼容的容器 runtime，負責處理由 OCI runtime spec 規定的所有命令，并啟動 kata-shim 實體。

kata-runtime 嚴重復用了 vircontainers 項目，該項目提供了一個通用的、runtime-spec 不可知的、硬件虛擬化的容器庫。

Configuration

Significant OCI commands

我們在這里描述下 kata-runtime 是如何處理最重要的 OCI命令的。

create

1. 在我們要啟動VM 與 shims進程的地方創建網絡命名空間。

2. 調用 pre-start hooks。其中之一應該負責創建主機網絡命名空間和預備新建的網絡命名空間之間的 veth 網絡對。

3. 在新的網絡命名空間里掃描網絡，在 veth接口與 tap接口之間創建一個 MACVTAP 連接到 VM。（？）（create a MACVTAP connection between the veth interface and a tap interface into the VM）

4. Start the VM inside the network namespace by providing the tap interface previously created.

start

exec

kill

delete

state

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的連接。

----未完待續----

總結

以上是生活随笔為你收集整理的Kata 架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。