Kata Containers及相关vmm介绍「建议收藏」

大家好，又见面了，我是你们的朋友全栈君。

Kata Containers介绍

Kata Containers 是轻量级虚拟机的一种新颖实现，可无缝集成到容器生态系统中。 Kata Containers 与容器一样轻巧快速，并与容器管理层集成，同时还提供 VM 的安全优势。

Kata Containers 是两个现有开源项目的合并：Intel Clear Containers 和 Hyper runV。 新项目结合了两种技术的优点，共同愿景是重组虚拟化以适应容器原生应用程序，以提供容器的速度和 VM 的安全性。Kata Containers 受益于每个项目的优势。Intel Clear Containers 专注于性能（<100 毫秒启动时间）和增强的安全性，而 Hyper runV 支持许多不同的 CPU 架构和管理程序。 通过合并这些项目，Kata Containers 在性能和兼容性方面都提供了卓越的最终用户体验。

Kata Containers特点

• 安全：在专用内核中运行，提供网络、I/O 和内存的隔离，并且可以利用具有虚拟化 VT 扩展的硬件强制隔离；
• 兼容性：支持行业标准，包括 OCI 容器格式、Kubernetes CRI 接口，以及传统虚拟化技术；
• 轻量：消除了在成熟的 VM 中嵌套容器的要求；
• 高性能：提供与标准 Linux 容器相同的性能；

Kata Containers提供简单的容器即服务能力，最终用户不需要学习或管理 COE（Kubernetes、Swarm、OpenShift）。支持网络功能虚拟化，提供了基于容器的 VNF 部署所需的多租户和安全性。

行业向容器的转变在保护多租户不可信环境中的用户工作负载方面提出了独特的挑战。 Kata Containers 利用开源管理程序作为每个容器（或 Pod 中的容器集合）的隔离边界； 解决了现有裸机容器解决方案的共享内核困境。Kata Containers 非常适合按需、基于事件的部署，例如无服务器功能、持续集成/持续交付，以及运行时间更长的网络服务器应用程序。在启动容器工作负载之前，开发人员不再需要了解有关底层基础设施的任何信息或执行任何类型的容量规划。 Kata Containers 提供增强的安全性、可扩展性和更高的资源利用率，使得整体堆栈更加简化。

Kata Containers2.0架构

Kata Containers 项目的主要交付物是 CRI 友好的Shim。它们背后还有一个 CRI 友好的API库。

Kata Containers 运行时与 OCI 运行时规范兼容，因此可以通过 CRI-O 和 Containerd 实现与 Kubernetes Container Runtime Interface (CRI) 无缝协作。Kata Containers 会为 kubelet (Kubernetes) 创建的每个pod 创建了一个 QEMU/KVM 虚拟机。

containerd-shim-kata-v2（shimv2）是 Kata Containers 入口点，它为 Kata 实现了 Containerd Runtime V2（Shim API）。

在 shimv2 之前（如 Kata Containers 1.x 版本中所做的那样），我们需要为每个容器和 Pod 沙箱本身创建一个 containerd-shim 和一个 kata-shim，并在 VSOCK 不可用时加上一个可选的 kata-proxy。使用 shimv2，Kubernetes 可以启动 Pod 和 OCI 兼容容器，每个 Pod 一个 shim（shimv2）而不是 2N+1 个 shim，并且即使没有 VSOCK 可用也没有独立的 kata-proxy 进程。

Kubernetes 与 shimv2 的集成

容器进程由 kata-agent 生成，kata-agent 是一个在虚拟机中作为守护进程运行的代理进程。 kata-agent 使用 VIRTIO serial或 VSOCK 接口在虚拟机中运行 ttRPC 服务器，QEMU 在主机上将其作为套接字文件公开。 shimv2 使用 ttRPC 协议与代理进行通信。该协议允许运行时向代理发送容器管理命令。该协议还用于在容器和管理引擎（例如 CRI-O 或 containerd）之间传输 I/O 流（stdout、stderr、stdin）。

对于任何给定的容器，init 进程和该容器内所有可能执行的命令，以及它们相关的 I/O 流，都需要通过 QEMU 导出的 VSOCK 接口。

容器工作负载，即实际的 OCI bundle rootfs，从主机导出到虚拟机。在配置基于块的图形驱动程序的情况下，将使用 virtio-scsi。在所有其他情况下，将使用 virtio-fs VIRTIO 挂载点，2.0版本默认使用virtio-fs。 kata-agent 使用这个挂载点作为容器进程的根文件系统。

虚拟化

Kata Containers 管理程序和 VMM 支持，Kata Containers 支持多个管理程序。下面提供了每个解决方案的详细信息和摘要。

QEMU/KVM

Kata Containers with QEMU 与 Kubernetes 完全兼容。

根据主机架构，Kata Containers 支持各种机器类型，例如 x86 系统上的 pc 和 q35，ARM 系统上的 virt 和 IBM Power 系统上的 pseries。默认的 Kata Containers 机器类型是 pc。机器类型及其机器加速器可以通过编辑运行时配置文件来更改。

使用的设备和功能：

• virtio VSOCK 或 virtio serial
• virtio block 或 virtio SCSI
• virtio net
• virtio fs 或 virtio 9p（推荐：virtio fs）
• VFIO
• 热插拔(hotplug)
• 机器加速器(machine accelerators)

Kata Containers 中使用机器加速器和热插拔来管理资源限制、缩短启动时间并减少内存占用。机器加速器：机器加速器是特定于架构的，可用于提高性能并启用机器类型的特定功能。 Kata Containers 中使用了以下机器加速器：

• NVDIMM：此机器加速器特定于 x86，仅受 pc 和 q35 机器类型支持。 nvdimm 用于提供根文件系统作为虚拟机的持久内存设备。
• 热插拔设备：Kata Containers VM 以最少的资源启动，从而缩短启动时间并减少内存占用。随着容器启动的进行，设备会热插拔到 VM。例如，当指定了包含附加 CPU 的 CPU 约束时，可以热添加它们。

Kata Containers 支持热添加以下设备：

• Virtio block
• Virtio SCSI
• VFIO
• CPU

Firecracker/KVM

Firecracker 建立在 rust-VMM 中的许多 Rust crate 之上，具有非常有限的设备模型，提供更轻的足迹和攻击面，专注于功能即服务之类的用例。因此，带有 Firecracker VMM 的 Kata Containers 支持 CRI API 的一个子集。 Firecracker 不支持文件系统共享，因此只支持基于块的存储驱动程序。 Firecracker 不支持设备热插拔，也不支持 VFIO。因此，带有 Firecracker VMM 的 Kata Containers 不支持启动后更新容器资源，也不支持设备透传。

Firecracker 在用户空间运行，并使用基于 Linux 内核的虚拟机 (KVM) 来创建 microVM。每个 microVM 的快速启动时间和低内存开销使您能够将数千个 microVM 打包到同一台机器上。这意味着每个功能、容器或容器组都可以用虚拟机屏障封装，使来自不同客户的工作负载能够在同一台机器上运行，而无需对安全性或效率进行任何权衡。

Firecracker 微型虚拟机使用基于 KVM 的虚拟化，可提供比传统虚拟机更高的安全性。这确保了来自不同终端客户的工作负载可以在同一台机器上安全运行。 Firecracker 还实现了一个最小设备模型，该模型排除了所有非必要功能并减少了 microVM 的攻击面。

除了最小的设备模型，Firecracker 还加速内核加载并提供最小的guest内核配置。这可以实现快速启动时间。 Firecracker 在短短 125 毫秒内启动用户空间或应用程序代码，并支持每台主机每秒高达 150 个微虚拟机的微虚拟机创建速率。

每个 Firecracker microVM 运行时的内存开销都低于 5 MiB，从而可以在每台服务器上打包高密度的 microVM。 Firecracker 提供了一个内置于每个 microVM 的速率限制器。这可以优化网络和存储资源的共享，甚至可以跨数千个 microVM。

Firecracker VMM 与处理器无关。具有硬件虚拟化支持的 64 位 Intel、AMD 和 Arm CPU 通常可用于生产工作负载。 Firecracker 是 QEMU 的替代品，专为安全高效地运行无服务器功能和容器而构建，仅此而已。 Firecracker 是用 Rust 编写的，为guest操作系统提供了一个最小所需的设备模型，同时排除了非必要的功能（只有 5 个模拟设备可用：virtio-net、virtio-block、virtio-vsock、serial console和一个最小的键盘控制器仅用于停止 microVM）。这与简化的内核加载过程一起实现了 < 125 ms 的启动时间和 < 5 MiB 的内存占用。 Firecracker 进程还提供 RESTful 控制 API，处理 microVM 的资源速率限制，并提供 microVM 元数据服务以实现主机和guest之间的配置数据共享。

使用的设备：

• virtio VSOCK
• virtio block
• virtio net

Cloud Hypervisor/KVM

Cloud Hypervisor 基于 rust-vmm，旨在为运行现代云工作负载提供更轻的占用空间和更小的攻击面。 Kata Containers with Cloud Hypervisor 提供了与 Kubernetes 的几乎完全兼容性，与 QEMU 配置相当。从 Kata Containers 的 1.12 和 2.0.0 版本开始，Cloud Hypervisor 配置支持 CPU 和内存调整、设备热插拔（磁盘和 VFIO）、通过 virtio-fs 共享文件系统、基于块的卷、从 VM 映像启动由 pmem 设备支持，并为每个 VMM 线程（例如所有 virtio 设备工作线程）提供细粒度的 seccomp 过滤器。

Cloud Hypervisor具有以下特点

• 安全：最少的模拟设备并在 Rust 中实现以避免许多常见的安全问题
• 快：通过直接内核启动，在不到 100 毫秒的时间内启动到用户空间
• 多OS：支持运行现代 Linux 和 Windows 客户机
• kata-containers：由 Kata Containers 支持，用于运行安全的容器化工作负载
• 强大的 REST API：使用 HTTP API 以编程方式控制 VM 的生命周期
• 轻量：密集部署的最小内存开销
• 跨平台：在 x86-64 和 aarch64 上运行
• 广泛的设备支持：支持广泛的半虚拟化设备和物理设备直通
• 实时迁移：不间断地将虚拟机从一台主机迁移到另一台主机

使用的设备和功能：

• virtio VSOCK or virtio serial
• virtio block
• virtio net
• virtio fs
• virtio pmem
• VFIO
• hotplug
• seccomp filters
• HTTP OpenAPI

概括

解决方案发布介绍简要总结：

虚拟机 Guest assets

管理程序将启动一个虚拟机，其中包括一个最小的guest kernel 和 一个guest image。

guest kernel

guest kernel被传递到管理程序并用于引导虚拟机。 Kata Containers 中提供的默认内核针对内核启动时间和最小内存占用进行了高度优化，仅提供容器工作负载所需的服务。这是基于最新的上游 Linux 内核。

Guest Image

Kata Containers 支持基于 initrd 和 rootfs 的最小guest image。

Root filesystem image

默认打包的根文件系统镜像，有时也称为“mini OS”，是一个基于 Clear Linux 的高度优化的容器引导系统。它提供了一个极小的环境并具有高度优化的引导路径。

在mini OS的上下文中运行的唯一服务是 init 守护进程 (systemd) 和代理。用户希望运行的实际工作负载是使用 libcontainer 创建的，以与 runc 相同的方式创建容器。

例如，当 ctr run -ti ubuntu date 运行时：

• 管理程序将使用guest kernel启动mini-OS镜像。
• systemd 在 mini-OS 上下文中运行，将在相同的上下文中启动 kata-agent。
• 代理将创建一个新的受限上下文以在（本例中的date为例）中运行指定的命令。
• 然后，代理将在此新上下文中执行命令，首先将根文件系统设置为预期的 Ubuntu 根文件系统。

Initrd image

一个压缩的 cpio(1) 存档，从一个加载到内存中的 rootfs 创建并用作 Linux 启动过程的一部分。在启动期间，内核将其解包到 tmpfs 的一个特殊实例中，该实例成为初始根文件系统。

在 initrd 上下文中运行的唯一服务是作为 init 守护程序的代理。用户希望运行的实际工作负载是使用 libcontainer 创建的，以与 runc 相同的方式创建容器。

Agent

kata-agent 是在guest os中运行的进程，作为管理容器和在这些容器中运行的进程的主管。

对于 2.0 版本，kata-agent 用 RUST 编程语言重写，以便我们可以最大限度地减少其内存占用，同时保持 Kata Container 1.x 中使用的原始 GO 版本的 kata-agent 的内存安全。这种内存占用的减少令人印象深刻，从几十兆字节减少到不到 100 千字节，使 Kata Containers 能够在更多用例中使用，例如功能计算和边缘计算。

kata-agent 执行单元是沙箱。 kata-agent 沙箱是由一组命名空间（NS、UTS、IPC 和 PID）定义的容器沙箱。 shimv2 可以为每个 VM 运行多个容器，以支持需要在 Pod 内运行多个容器的容器引擎。

kata-agent 通过 ttRPC 与其他 Kata 组件通信。

Runtime

containerd-shim-kata-v2 是一个容器运行时 shimv2 实现，负责处理运行时 v2 shim API，它类似于 OCI 运行时规范，但通过一次加载运行时并进行 RPC 调用来处理各种容器来简化架构生命周期命令。这种改进是对 OCI 规范的改进，该规范要求容器管理器多次调用运行时二进制文件，每个生命周期命令至少调用一次。

containerd-shim-kata-v2 大量使用了 virtcontainers 包，它提供了一个通用的、运行时无感知的、硬件虚拟化的容器库。

Configuration

运行时使用名为 configuration.toml 的 TOML 格式配置文件。默认情况下，此文件安装在 /usr/share/defaults/kata-containers 目录中，包含各种设置，例如虚拟机管理程序、guest kernel和mini-OS的路径。

可以通过运行来确定实际的配置文件路径：

$ kata-runtime –show-default-config-paths

大多数用户不需要修改配置文件。

该文件的注释很好，并提供了一些选项，可用于修改运行时和您选择的管理程序的行为。

配置文件还用于启用运行时调试输出。

Networking

容器通常存在于它们自己的，也可能是共享的网络命名空间中。 在容器生命周期的某个时刻，容器引擎将设置该命名空间以将容器添加到与主机网络隔离但在容器之间共享的网络

为此，容器引擎通常会将虚拟以太网（veth）对的一端添加到容器网络命名空间中。 veth 对的另一端被添加到主机网络命名空间。

这是一种非常以命名空间为中心的方法，因为许多管理程序VMM 无法处理 veth 接口，veth接口常用于在不同命名空间之间通信，使用同一个内核协议栈，不同虚拟机有不同的内核协议栈。 通常，TAP 接口是为 VM 连接创建的。

为了克服典型容器引擎期望与虚拟机之间的不兼容性，Kata Containers 网络使用流量控制透明地将 veth 接口与 TAP 接口连接起来：

使用 TC 过滤器，在容器网络和虚拟机之间创建重定向。 例如，CNI 可以在容器的网络命名空间中创建一个设备 eth0，它是一个 VETH 设备。 Kata Containers 将为虚拟机创建一个 tap 设备，tap0_kata，并设置一个 TC 重定向过滤器，以将流量从 eth0 的入口镜像到 tap0_kata 的出口，然后将流量从 tap0_kata 的入口镜像到 eth0 的出口。

Kata Containers 保持对 MACVTAP 的支持，这是 Kata 中使用的早期实现。 TC-filter 是默认设置，因为它允许更简单的配置、更好的 CNI 插件兼容性以及与 MACVTAP 相当的性能。

由于缺乏相对于 TC-filter 和 MACVTAP 的性能，Kata Containers 已弃用对桥接的支持。

Kata Containers 支持 CNM 和 CNI 进行网络管理。

Network Hotplug

Kata Containers 开发了一组网络子命令和 API，用于添加、列出和删除访客网络端点以及操作访客路由表。

下图说明了 Kata Containers 网络热插拔工作流程。

Storage

容器工作负载通过 virtio-fs 与虚拟化环境共享。

（virtio-fs和devicemapper区别Virtio-fs介绍与性能优化_guest）

devicemapper 快照程序是一个特例。快照程序使用专用的块设备而不是格式化的文件系统，并在块级别而不是文件级别运行。该知识用于直接使用底层块设备而不是覆盖文件系统作为容器根文件系统。块设备映射到覆盖层的顶部读写层。与使用 virtio-fs 共享容器文件系统相比，这种方法提供了更好的 I/O 性能。

Kata Containers 具有热插拔和移除块设备的能力，这使得在 VM 启动后启动的容器可以使用块设备。

用户可以通过在容器内调用 mount(8) 来检查容器是否使用 devicemapper 块设备作为其 rootfs。如果使用 devicemapper 块设备，/ 将挂载在 /dev/vda 上。用户可以通过运行时配置禁用底层块设备的直接挂载。

版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。

发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/192610.html原文链接：https://javaforall.cn