★ FEATURED ARTICLE 云原生容器运行时【免费下载链接】kata-containersKata 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. https://katacontainers.io/项目地址https://gitcode.com/gh_mirrors/ka/kata-containers点击查看免费下载本文基于 Kata Containers 仓库中的安装文档 docs/installation.md 展开系统讲解 Kata Containers 的三条安装路径——Kubernetes Helm 部署推荐、预构建发布包安装与源码构建并完整覆盖安装前必须满足的硬件前提CPU 虚拟化扩展、KVM、嵌套虚拟化、vhost 内核模块与软件前提。读完本文你可以独立完成 Kata 的部署理解 RuntimeClass 命名规则、shim 配置文件加载顺序等关键机制并通过uname -r验证工作负载确实运行在轻量虚拟机中。概览两个运行时与三种安装方式Kata Containers 同时提供两个运行时遗留的 Go 运行时位于 src/runtime和 Rust 实现的 containerd shim v2——runtime-rs位于 src/runtime-rs。自 4.0.0 版本起runtime-rs是默认且推荐的选择Go 运行时仍在发布和支持范围内但已被弃用deprecation迁移细节见 Go runtime deprecation 说明。三种安装方式各有适用场景方式适用场景说明Kata Deploy Helm ChartHelm 部署Kubernetes推荐。在每个节点安装所有必需构件并创建 KataRuntimeClass通过helm upgrade/helm uninstall完成升级与卸载预构建发布包 tarball发布包安装Docker、单节点手动安装升级和清理需自行负责源码构建源码构建开发者与贡献者自行构建各个组件硬件前提CPU 虚拟化扩展、KVM 与 vhost 模块以下要求与安装方式无关在每一个运行 Kata 工作负载的主机上都必须满足裸机或启用了嵌套虚拟化的虚拟机。CPU 虚拟化扩展必须启用各架构对应的虚拟化技术架构虚拟化技术x86_64/amd64Intel VT-x (vmx)、AMD-V (svm)aarch64(arm64)ARM Hypppc64leIBM Powers390xIBM Z LinuxONE SIE在x86_64上确认扩展已暴露给操作系统无任何输出说明虚拟化不可用grep -E -o (vmx|svm) /proc/cpuinfo | sort -uKVM 设备可用/dev/kvm必须存在且运行 Kata shim 的用户root或kvm组成员可访问ls -l /dev/kvm若x86_64主机缺少/dev/kvm按 CPU 厂商加载 KVM 模块sudo modprobe kvm_intel # Intel 主机 sudo modprobe kvm_amd # AMD 主机提示Microsoft Hypervisor / Hyper-V / Azure在由 Microsoft Hypervisor 支撑的主机上包括 Windows 上的嵌套 Linux 虚拟机和部分 Azure 实例类型KVM 不可用对应的设备是/dev/mshv。此时需要一个支持 mshv 的 VMM例如 Cloud Hypervisor 的 mshv 后端对应clh-azure/clh-azure-runtime-rs这两个 runtime class。嵌套虚拟化当主机本身是一台虚拟机时底层 hypervisor 必须把 CPU 虚拟化扩展暴露给客户机例如使用host-passthrough或host-modelCPU并在裸金属宿主机上启用嵌套。可以用systemd-detect-virt判断当前处于裸机还是虚拟机systemd-detect-virt输出none直接运行在裸机上输出kvm、qemu等运行在虚拟机内需要在底层宿主机上启用嵌套虚拟化。vhost 内核模块必须加载Kata 通过 VSOCK 在运行时与 guest agent 之间通信vhost_vsock提供/dev/vhost-vsock网络则需要vhost_netsudo modprobe vhost_vsock sudo modprobe vhost_net如需开机自动加载printf vhost_vsock\nvhost_net\n | sudo tee /etc/modules-load.d/kata-containers.conf软件前提需要哪些软件取决于所选安装方式Kubernetes ≥ v1.22—— CRI v1 API 成为默认、RuntimeClass脱离 alpha 的首个版本。更早的集群需要 feature gate 或 CRI shim超出本文范围。兼容 CRI 的容器运行时containerd 或 CRI-O。推荐 containerdv2.1.x或更新版本multiInstallSuffix特性与 drop-in 配置合并要求 containerdv2.0。详细的 containerd 配置见 prerequisites。Kata Containers ≥ 3.12走 Helm 安装时——v3.12.0是首个在 releases 页面发布 Helm chart 的版本。helm命令行工具Kubernetes 安装方式必需。Dockerv26如果要用 Docker 直接运行 Kata Containers。在 Kubernetes 上用 Helm 安装推荐helm用于安装模板化的 Kubernetes 清单。Kata Deploy Helm chart 会把每个节点需要的全部 Kata 二进制和构件部署到位并创建 KataRuntimeClass资源。chart 的源码位于 tools/packaging/kata-deploy/helm-chart参数定义见 values.yaml。安装 chart# 选择要安装的版本或直接使用最新 release。 export VERSION$(curl -sSL https://api.github.com/repos/kata-containers/kata-containers/releases/latest | jq -r .tag_name) export CHARToci://ghcr.io/kata-containers/kata-deploy-charts/kata-deploy helm install kata-deploy ${CHART} --version ${VERSION}默认采用短期、分阶段的逐节点 JobdeploymentMode: job完成安装并在集群中创建默认的 KataRuntimeClass资源。查看全部可配置项helm show values ${CHART} --version ${VERSION}查看可用的 chart 版本helm show chart ${CHART}完整的配置选项shim 选择、自定义运行时、节点选择、TEE shim、drop-in 配置文件等见 Helm 配置文档。说明部署模式Job vs DaemonSet短期、分阶段的逐节点 Job节点上不留常驻组件是默认安装模型deploymentMode: job。也可以设置deploymentMode: daemonset改用常驻的kata-deployDaemonSet。两种模式的差异与节点选择选项见 Deployment Modes。从 chart 模板结构看Job 模式的核心模板包括 安装 Job、RuntimeClass 清单 和 RBAC 清理 Job。使用 Kata RuntimeClasschart 会为每个启用的 shim 创建一个RuntimeClass。基于runtime-rs的运行时带-runtime-rs后缀例如kata-qemu-runtime-rskata-dragonball内置 Dragonball VMM仅提供runtime-rs版本弃用的 Go 运行时对应kata-qemu。列出集群中可用的 runtime classkubectl get runtimeclasses运行一个测试 Pod将 Pod 调度到runtime-rs的RuntimeClass上确认安装成功apiVersion: v1 kind: Pod metadata: name: kata-runtime-rs-test spec: runtimeClassName: kata-qemu-runtime-rs containers: - name: test image: quay.io/libpod/ubuntu:latest command: [uname, -r]kubectl apply -f kata-qemu-runtime-rs-test.yaml kubectl logs kata-runtime-rs-test打印出的内核版本是 Kataguest 内核通常与宿主机内核uname -r不同——这就证明工作负载运行在轻量虚拟机内。卸载helm uninstall kata-deploy -n kube-system卸载时 Helm 会报告部分集群级资源ServiceAccount、ClusterRole、ClusterRoleBinding因 resource policy 被保留这是正常现象一个 post-delete hook Job 会随后删除它们确保不残留任何集群级 RBAC对应模板 kata-deploy-cleanup-job.yaml。从预构建发布包安装当不使用 Kubernetes 时例如配合 Docker 运行 Kata从发布包安装。按自身架构从 releases 页面下载归档export VERSION$(curl -sSL https://api.github.com/repos/kata-containers/kata-containers/releases/latest | jq -r .tag_name) # Release tarball 使用的架构名与 uname -m 不同。 case $(uname -m) in x86_64) ARCHamd64 ;; aarch64) ARCHarm64 ;; s390x) ARCHs390x ;; ppc64le) ARCHppc64le ;; *) echo unsupported architecture: $(uname -m) 2 exit 1 ;; esac curl -fsSL -o kata-static.tar.zst \ https://github.com/kata-containers/kata-containers/releases/download/${VERSION}/kata-static-${VERSION}-${ARCH}.tar.zst # 归档使用 /opt/kata/ 前缀。 sudo tar -xvf kata-static.tar.zst -C /kata-static归档包含 runtime-rs、其配置文件、可组合 guest 镜像composable guest images以及共享宿主组件路径运行时/opt/kata/runtime-rs/bin/containerd-shim-kata-v2runtime-rs默认打包的配置文件位于/opt/kata/share/defaults/kata-containers/下。runtime-rs的配置文件使用-runtime-rs后缀例如configuration-qemu-runtime-rs.toml而configuration-dragonball.toml选择内置 Dragonball VMM——对应的上游模板分别为 configuration-qemu-runtime-rs.toml.in 与 configuration-dragonball.toml.in。注意Go 运行时已弃用如果仍需 Go 运行时或单体式monolithicguest 镜像必须单独安装kata-go-static归档curl -fsSL -o kata-go-static.tar.zst \ https://github.com/kata-containers/kata-containers/releases/download/${VERSION}/kata-go-static-${VERSION}-${ARCH}.tar.zst sudo tar -xvf kata-go-static.tar.zst -C /Go shim 安装在/opt/kata/bin/containerd-shim-kata-v2。用 Docker 运行 Kata ContainersDockerv26可以直接用 Kata shim 启动容器该路径以 QEMU 作为 VMM 进行了测试。步骤先按上一节从发布包安装然后在 Docker daemon 配置中注册一个 Kata 运行时。使用runtime-rs时把 Docker 指向runtime-rsshim并用ConfigPath指定runtime-rs配置文件{ runtimes: { kata: { runtimeType: /opt/kata/runtime-rs/bin/containerd-shim-kata-v2, options: { ConfigPath: /opt/kata/share/defaults/kata-containers/runtime-rs/configuration-qemu-runtime-rs.toml } } } }该 JSON 写入/etc/docker/daemon.json。关于ConfigPath它决定 shim 加载哪份配置——QEMU 用configuration-qemu-runtime-rs.toml内置 Dragonball VMM 用configuration-dragonball.toml。省略时shim 回退到默认搜索路径/etc/kata-containers/下的配置文件优先于打包默认值。重启 Docker daemon 并启动一个 Kata 容器sudo systemctl restart docker docker run --runtime kata -it --rm ubuntu:24.04 uname -r打印出的内核是 Kata guest 内核通常与宿主机不同。注意Docker-in-Docker在 Kata 容器内部运行docker需要额外处理见 How to run Docker in Docker with Kata Containers。源码视角shim 的配置文件加载顺序从 runtime-rs 的配置加载实现 看load_config按以下优先级确定配置文件环境变量KATA_CONF_FILE——且必须是“随发行版一起发布的配置文件”与默认搜索列表匹配否则报错拒绝shimv2 create task option 中携带的config_path即 Docker/containerd 侧传入的ConfigPath以上都未设置时按 DEFAULT_RUNTIME_CONFIGURATIONS 的顺序查找/etc/kata-containers/runtime-rs/configuration.toml /usr/share/defaults/kata-containers/runtime-rs/configuration.toml /opt/kata/share/defaults/kata-containers/runtime-rs/configuration.toml因此发布包安装的默认配置位于第 3 条路径若要全局覆盖把配置放到/etc/kata-containers/runtime-rs/configuration.toml即可无需改动ConfigPath。加载完成后配置还会经过validate()校验并支持用 annotation 对配置项做逐沙箱覆盖。源码构建与开发者入口开发者和贡献者可以从源码构建 Kata 的各组件运行时、agent、guest 内核、rootfs/initrd 镜像与 hypervisor 的构建指南见 Developer GuideRust shim包括内置 Dragonball VMM 与外部 hypervisor 选项见 runtime-rs README。关键路径速查内容路径 / 位置runtime-rs shim发布包安装/opt/kata/runtime-rs/bin/containerd-shim-kata-v2Go shim弃用单独归档/opt/kata/bin/containerd-shim-kata-v2打包配置目录/opt/kata/share/defaults/kata-containers/默认配置搜索顺序DEFAULT_RUNTIME_CONFIGURATIONSHelm chart 源码tools/packaging/kata-deploy/helm-chartHelm 配置参考docs/helm-configuration.mdcontainerd 详细前提docs/prerequisites.mdGo → runtime-rs 迁移docs/migrating-config-go-runtime-to-runtime-rs.md最后验证安装成功的通用信号只有一个uname -r在 Kata 沙箱内打印的是 guest 内核版本与宿主机内核不同。赞分享云原生容器运行时【免费下载链接】kata-containersKata 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. https://katacontainers.io/项目地址https://gitcode.com/gh_mirrors/ka/kata-containers点击查看免费下载相关推荐Porffor项目新型运行时内存分配器设计与实现Porffor项目新型运行时内存分配器设计与实现 背景与挑战 Porffor作为一款创新的编程语言工具链其原有的内存分配机制主要依赖编译期静态分配。这种设计虽云原生容器运行时Kata Containers 与 containerd 集成安装实战从二进制部署到 CRI 运行时验证Kata Containers 与 containerd 集成安装实战从二进制部署到 CRI 运行时验证 本篇基于 Kata Containers 仓库中的云原生容器运行时超强安全隔离Kata Containers实战部署与运维指南超强安全隔离Kata Containers实战部署与运维指南 还在为容器安全隔离问题头疼想获得虚拟机级别的安全性却不想牺牲容器性能一文解决你的困境读完本云原生容器运行时上一篇CANN/pypto PTO前端开发者文档下一篇Apisauce现代化JavaScript网络请求库的完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
阅读完成 · 觉得有帮助？
 报错全解析：从驱动冲突到UUID修复)
