Kata Containers runtime-rs 沙箱开销配置指南：overhead_vcpus / overhead_memory 与 Kubernetes podFixed 对齐

云原生容器运行时【免费下载链接】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 的 runtime-rs 实现中两个关键的沙箱资源开销参数 ——overhead_vcpus与overhead_memory讲解它们如何参与静态沙箱资源管理static_sandbox_resource_mgmt下的 VM 资源计算以及管理员应如何与 KubernetesRuntimeClass.overhead.podFixed协同配置实现可预测、可核算的生产级沙箱规格。读完本文你将掌握 overhead 参数的完整 sizing 模型、四类典型配置场景的精确计算结果、Helm 部署中的落地写法以及底层InitialSizeManager的源码级实现细节。[!WARNING] 对于 runtime-rs使用static_sandbox_resource_mgmt是推荐模式为生产沙箱规格而关闭它并不推荐。[!IMPORTANT] 要在 Kubernetes 中获得正确且可预测的 Kata 沙箱规格工作负载的 CPU 与内存 limits必须设置。未设置 limits 时runtime-rs 会回退到default_vcpus与default_memory—— 这只是兼容性回退并非预期的生产规格模型。为什么需要 overhead 字段在 runtime-rs 中静态沙箱资源管理static sandbox sizing默认启用。Kata 必须在启动工作负载之前就确定 VM 资源。在 Kubernetes 中pod 的 limits 代表工作负载资源但 VM 本身还需要额外的资源来承载 guest 内核、运行时组件以及各种系统开销。overhead_vcpus与overhead_memory正是这份“额外预算”。它们被定义在 hypervisor 配置节中例如 configuration-qemu-runtime-rs.toml.in 中对该参数的注释# Guest-side vCPU overhead budget (fractional) used with static_sandbox_resource_mgmt. # When workload limits are present, vm_vcpus requested_vcpus overhead_vcpus # (rounded up at boot). If a workload limit is set on another dimension (for example # memory) but CPU is missing, requested_vcpus is treated as 0 and vm_vcpus equals # overhead_vcpus (minimum 1 at boot). When no workload limits are present, # default_vcpus is used instead. overhead_vcpus DEFOVERHEADVCPUS_QEMU# Guest-side memory overhead budget (MiB) used with static_sandbox_resource_mgmt. # When workload limits are present, vm_memory requested_memory overhead_memory. # If a workload limit is set on another dimension (for example CPU) but memory is # missing, requested_memory is treated as 0, so vm_memory equals overhead_memory. # When no workload limits are present, default_memory is used instead. overhead_memory DEFOVERHEADMEMSZ_QEMU注意配置文件模板中的值以DEFOVERHEADVCPUS_*、DEFOVERHEADMEMSZ_*形式的宏占位符呈现实际默认值在构建期由 src/runtime-rs/Makefile 注入具体见后文“出厂默认值”小节。静态规格模型在 runtime-rs 静态沙箱规格static sandbox sizing模式下Kata 按以下规则计算 VM 资源若工作负载设置了 limitsvm_vcpus requested_vcpus overhead_vcpusvm_memory requested_memory overhead_memory若工作负载未设置 limitsvm_vcpus default_vcpusvm_memory default_memory换言之default_*是“无 limits”场景的回退值而overhead_*是“已设置 limits”场景的加性预算。对 CPU 而言runtime-rs 将工作负载值与 overhead 值相加若计算结果为小数则向上取整ceil因为 VMM 只能暴露整数个 vCPU同时在 limit 驱动的路径上强制至少1个 vCPU包括0 0的边界情况。内存方面工作负载的 memory limit 会被按 2 MiB 对齐取整到下一个偶数 MiB以兼容大页hugepage支持。这一模型在源码层面由 initial_size.rs 中的setup_config精确实现if self.resource.vcpu 0.0 || self.resource.mem_mb 0 { if self.resource.vcpu 0.0 { info!(sl!(), resource with vcpu {}, self.resource.vcpu); } if self.resource.mem_mb 0 { info!(sl!(), resource with memory {}, self.resource.mem_mb); } hv.cpu_info.default_vcpus (hv.cpu_info.overhead_vcpus self.resource.vcpu).max(1.0); hv.memory_info.default_memory hv.memory_info.overhead_memory self.resource.mem_mb; hv.memory_info.default_maxmemory hv .memory_info .default_maxmemory .max(hv.memory_info.default_memory); } hv.cpu_info.default_maxvcpus hv.cpu_info.default_vcpus.ceil() as u32;其中.max(1.0)保证了 limit 驱动路径下最小 1 个 vCPUceil()则落实小数向上取整内存路径同时把default_maxmemory钳制到不小于计算结果。整个模块对应的参数化单元测试test_setup_config_static_requested_vs_defaults覆盖了双 limits、仅 CPU limit、仅内存 limit、零 overhead、纯默认回退等组合场景见 initial_size.rs 测试段。资源来源注解与 OCI specrequested_vcpus与requested_memory并非凭空而来。从 initial_size.rs 可以看到InitialSizeManager有两种构造来源PodSandbox沙箱从运行时containerd / CRI-O写入沙箱注解的 CPU quota、CPU period 与内存 limit 中解析get_sizing_info会优先读取 containerd 风格注解若三者全为 0 则回退读取 CRI-O 的pod_linux_resourcesJSON 注解单容器如docker run直接读取 OCI spec 中linux.resources.cpu与linux.resources.memory.limit。若某维度缺失则该维度按0参与计算最终由overhead_*兜底。静态与非静态模式的差异static_sandbox_resource_mgmt决定上述计算是否生效。在 initial_size.rs 中非静态模式会跳过 overhead 计算、保留配置中的默认值而在 manager_inner.rs 中可以看到非静态模式下 runtime-rs 会动态更新沙箱的 CPU/内存资源。静态模式下则完全以启动前计算出的固定值为主。runtime-rs 的configuration-remote.toml.in等模板中static_sandbox_resource_mgmt true即默认静态模式。把 podFixed 当作“规格函数”请将RuntimeClass.overhead.podFixed视为期望 VM 大小的函数VM 越大通常需要越大的 overhead 预算 —— 这一点对静态分配与动态分配环境都成立。操作层面这通常归结为两种模型单一 runtime class一个保守的podFixed值覆盖所有预期的负载规模多个 runtime class如 S/M/L/XL每个 class 配备量身定制的podFixed与运行时 profile以获得更紧致的节点级资源核算。Kata 无法为这个函数给出一个放之四海而皆准的单一值因为它取决于大量部署特定因素包括使用的 hypervisor不同 hypervisor 的内存/CPU 占用不同文件共享机制virtio-fs还是其他是否包含 CoCoConfidential Containersguest 组件使用的 VM 镜像官方发布镜像还是下游修改过的镜像硬件特性如 GPU或任何需要大块 DMA buffer 的设备。这些因素、overhead 测量固有的不稳定性以及集群所有者愿意为稳定运行“浪费”多少余量都会影响该值。因此下游运维人员应当针对自己的部署实测并调优这个函数。出厂默认值从 Makefile 读取实际数字Kata 各 hypervisor profile 的overhead_*默认值定义在 src/runtime-rs/Makefile下表整理了当前仓库中的实际取值宏变量默认值适用 runtimeDEFOVERHEADVCPUS_QEMU0.2qemuDEFOVERHEADMEMSZ_QEMU32MiBqemuDEFOVERHEADVCPUS_CLH0.2cloud-hypervisorDEFOVERHEADMEMSZ_CLH32MiBcloud-hypervisorDEFOVERHEADVCPUS_OPENVMM0.2OpenVMMDEFOVERHEADMEMSZ_OPENVMM32MiBOpenVMMDEFOVERHEADVCPUS_DB0.2dragonballDEFOVERHEADMEMSZ_DB32MiBdragonballDEFOVERHEADVCPUS_TEE0.4SNP/TDX 等 TEE runtimeDEFOVERHEADMEMSZ_TEE128MiBSNP/TDX runtimeDEFOVERHEADMEMSZ_TEE_SE768MiBIBM SE runtime含 512 MiB swiotlb 反弹缓冲区DEFOVERHEADVCPUS_NV0.5qemu-nvidia-gpu 系列DEFOVERHEADMEMSZ_NV512MiBqemu-nvidia-gpu 系列DEFOVERHEADMEMSZ_NV_BASE128MiBqemu-nvidia-cpu可见 TEE 与 GPU 场景的 overhead 显著更高 —— 这与文档所述“CoCo guest 组件、GPU DMA buffer”会推高 overhead 的判断一致。这些值仅是策略输入下游运维与管理员必须按自身环境调优。推荐的运维/管理员工作流Kubernetes 文档将RuntimeClass.overhead.podFixed定义为podFixed represents the fixed resource overhead associated with running a pod.对 Kata 而言这份 overhead 由两部分构成guest 侧 overheadVM 在工作负载之上额外需要的 CPU/内存与host 侧 overhead运行在节点上的 runtime、hypervisor 及辅助进程。podFixed必须同时覆盖两者而 Kata 的overhead_*只覆盖 guest 侧部分。因此一个实用的工作流是估算或实测guest 侧 overhead。Kata profile 自带起始值但你应针对自己的环境精调将 Kataoverhead_*按 runtime profile 设置为该 guest 侧值估算或实测host 侧 overhead将RuntimeClass.overhead.podFixed设置为 guest 侧与 host 侧 overhead 之和 —— 这自然保证podFixed高于overhead_*用有代表性的工作负载小/中/大验证。粗略的测量起点如下guest 侧 overhead用容器名义 VM 大小减去容器内实际已用内存例如在容器内执行freehost 侧 overhead用 pod 的 host cgroup 用量减去名义 VM 大小例如cat /sys/fs/cgroup/kubepods.slice/**/memory.current。面向生产的 Kata 部署应假定用户提供工作负载 limits。无 limits 的路径只是兼容性回退不是主要的规格模型。Kata profile 会把overhead_*初始化为派生自 Pod Overhead 的值例如 CPU 与内存均取 80%但这仅是策略输入需要下游运维与管理员调优。谁设置什么管理员 vs 用户在许多环境中“管理员”与“用户”是不同角色在较小环境中可能是同一个人或团队。管理员/运维职责设置 runtime 默认值default_*与 overhead 值overhead_*设置并维护RuntimeClass.overhead.podFixed提供用户可按工作负载 profile 选择的 runtime class确保每个 runtime profile 的这些策略相互对齐用有代表性的工作负载验证行为必要时调整。用户/应用职责为工作负载意图设置 pod/container 的 CPU 与内存 limits使用管理员按工作负载 profile 提供的 runtime class在需要确定性资源时避免依赖默认规格。示例 1CPU 与内存均设置 limits标准生产场景场景意图展示带显式工作负载 limits 的标准生产用例。结果用户获得可预测的规格外加管理员定义的 overhead 预算。与RuntimeClass.overhead.podFixed的关系podFixed应高于overhead_*因为podFixed必须包含 host 侧 runtime 组件。给定 runtime profiledefault_vcpus 2default_memory 1024overhead_vcpus 0.5overhead_memory 128以及匹配的RuntimeClass.overhead.podFixedcpu 600m0.6memory 160Mi工作负载 limitsCPU quota/period 等价于1.5 vCPUs内存 limit600 MiBKata VM 规格guest 侧vm_vcpus 1.5 0.5 2.0vm_memory 600 128 728 MiBKubernetes 对整个 pod 的核算sum(limits) podFixedpod_cpu 1.5 0.6 2.1pod_memory 600 160 760 MiB注意podFixed160Mi高于overhead_memory128因为它还必须覆盖 VM 之外运行的 host 侧 runtime 组件。示例 2部分 limits按维度拆分场景意图展示只提供一种 limit 时会发生什么。结果一旦存在任意 limitoverhead 逻辑就会作用于两个维度。与RuntimeClass.overhead.podFixed的关系与示例 1 相同podFixed应保持高于overhead_*。给定default_vcpus 2default_memory 1024overhead_vcpus 0.5overhead_memory 1282A. 仅内存 limit工作负载设置内存 limit 512 MiB无 CPU limit结果CPU 向上取整用于启动vm_vcpus ceil(0 0.5) 1内存使用 overhead 公式vm_memory 512 128 640 MiB2B. 仅 CPU limit工作负载设置CPU quota/period 等价于1.5 vCPUs无内存 limit结果CPU 使用 overhead 公式vm_vcpus 1.5 0.5 2.0内存仍使用 overhead 基线vm_memory 0 128 128 MiB这正是工作负载内存 limits必须设置的原因见本文开头的 IMPORTANT 提示只有 CPU limit 而无内存 limit 时VM 仅按overhead_memory规格几乎必然太小而无法运行真实负载。它是显式的 overhead 基线而不是回退到default_memory的默认值。作为安全网如果计算出的沙箱内存为0例如overhead_memory 0且只有 CPU limit 的工作负载runtime-rs 会提前失败并给出可操作的错误信息而不是启动一个无法使用的 VM。该错误校验在 initial_size.rs 的validate_non_zero_sandbox_memory中实现其报错文案为computed sandbox memory is 0 MiB for hypervisor name; set a non-zero memory limit or configure non-zero default_memory/overhead_memory这与 runtime-rs 的行为一致一旦沙箱存在 limitsoverhead 会作用于两个维度缺失的维度使用0 overhead_*分数 CPU 结果向上取整。示例 3overhead_* 0零开销模型场景意图用户通过设置overhead_* 0实现精确的工作负载规格。结果设置 limits 时用户得到与请求完全一致的 VM 大小但需要自行在 limits 中核算工作负载相关的开销。与RuntimeClass.overhead.podFixed的关系podFixed仍需覆盖 host 侧资源占用而非 guest 侧并应独立调优。某些部署可能选择设置overhead_vcpus 0overhead_memory 0配合default_vcpus 2default_memory 10243A. 两个维度均设置 limits工作负载 limitsCPU 1.5 vCPUs内存 600 MiB结果vm_vcpus 1.5 0 1.5vm_memory 600 0 600 MiB3B. 无 limits结果vm_vcpus default_vcpus 2vm_memory default_memory 1024 MiB这样默认值仅作为回退而 limit 驱动的规格则完全基于工作负载本身。示例 4无 limits回退路径场景意图展示用户未提供 limits 时的兼容性回退行为。结果VM 规格来自管理员定义的默认值。这对基础负载与测试是可接受的但不是预期的生产规格姿态。与RuntimeClass.overhead.podFixed的关系此时podFixed应高于有效的默认基线default_*以覆盖 host 侧组件。Kubernetes 并不知道 Kata 的default_*值若podFixed过低host 侧占用可能超出 pod 预算pod 可能被杀死OOM/驱逐。给定default_vcpus 2default_memory 1024MiBoverhead_vcpus 0.5overhead_memory 128MiBPod/container 未设置 limits。结果VM 以2 vCPUs与1024 MiB启动此场景不使用overhead_*。Runtime profile 配置片段最直接的落地方式是在 hypervisor 配置节中直接设置这四个参数[hypervisor.qemu] default_vcpus 2 default_memory 1024 overhead_vcpus 0.5 overhead_memory 128需要留意的是overhead_vcpus支持小数值例如0.5、0.2因为它代表“额外预算”而非最终启动值最终启动的 vCPU 数会由 runtime-rs 向上取整。overhead_memory以 MiB 为单位。Helm 部署示例使用 kata-deploy Helm 时推荐模式是在 runtime 的dropIn中设置overhead_*并在同一个 values 文件中将对应的RuntimeClass.overhead.podFixed设置为更高的值。对于 runtime-rsstatic_sandbox_resource_mgmt默认已启用因此这些示例聚焦于overhead_*及相关策略值。示例 A自定义 runtime profilecustomRuntimes: enabled: true runtimes: my-qemu-runtime-rs: baseConfig: qemu dropIn: | [hypervisor.qemu] default_vcpus 2 default_memory 1024 overhead_vcpus 0.5 overhead_memory 128 runtimeClass: | kind: RuntimeClass apiVersion: node.k8s.io/v1 metadata: name: kata-my-qemu-runtime-rs labels: app.kubernetes.io/managed-by: kata-deploy handler: kata-my-qemu-runtime-rs overhead: podFixed: cpu: 600m memory: 160Mi scheduling: nodeSelector: katacontainers.io/kata-runtime: true在该示例中用于 VM 规格的 Kata overhead 是0.5 vCPU与128MiKubernetes 调度/核算 overhead 是600m与160Mi两者之差podFixedoverhead_*为 guest 工作负载 cgroup 模型之外的组件预留了额外预算。示例 B用shims.shim.dropIn覆盖默认 shim若不需要新建 runtime class可以直接修补现有的 runtime-rs shimshims: qemu: enabled: true dropIn: | [hypervisor.qemu] overhead_vcpus 0.5 overhead_memory 128这会更新该 shim 的 Kata 规格行为。如果你同时在外部维护 runtime class YAML请在同一规格策略下保持podFixed大于overhead_*。Kubernetes 对齐注意事项RuntimeClass.overhead.podFixed与 Kataoverhead_*应由同一运维/管理员策略管理且podFixed应设置得高于overhead_*两者取值不匹配时在资源压力下可能产生意外行为例如 pod 实际 host 占用超出sum(limits) podFixed的预算而被驱逐上游 runtime-rs 不会自动从 Kubernetes 获取 RuntimeClass overhead配置的overhead_*值才是 VM 规格的唯一来源这一点可从 initial_size.rs 的实现得到印证所有计算均基于注解/OCI spec 与 TOML 配置并不存在对 Kubernetes API 的读取路径。结论与建议overhead_vcpus/overhead_memory是 runtime-rs 静态沙箱规格模型中连接“工作负载 limits”与“VM 实际资源”的桥接参数它们让 Kata 能在启动前计算出包含 guest 侧开销的准确 VM 大小同时把 host 侧开销留给RuntimeClass.overhead.podFixed核算。生产部署的关键纪律是用户设置 limits管理员对齐overhead_*与podFixed并保证podFixed始终高于overhead_*。具体的数值没有通用答案务必结合 hypervisor、文件共享方式、CoCo 组件与硬件特性参照本文的工作流实测调优。赞分享云原生容器运行时【免费下载链接】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 配置迁移实战从 Go Runtime 到 runtime-rs 的 QEMU 配置完整对照与移植指南Kata Containers 配置迁移实战从 Go Runtime 到 runtime rs 的 QEMU 配置完整对照与移植指南 Kata Contain云原生容器运行时Kata Containers runtime-rs 中 VM 模板VM Templating的配置与实战指南Kata Containers runtime rs 中 VM 模板VM Templating的配置与实战指南 本文聚焦 Kata Containers 的云原生容器运行时Kata Containers Pod 注解完全指南按 Pod 粒度定制沙箱配置Kata Containers Pod 注解完全指南按 Pod 粒度定制沙箱配置 导读 本文基于 Kata Containers 官方运维指南 how to云原生容器运行时上一篇RobustVideoMatting的Laplacian Loss函数解析训练稳定性优化的终极指南下一篇macOS系统监控神器eul的权限申请与数据安全指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考