设置 runtimeclassname: kata 可使高危应用调度至kata沙箱，前提是宿主机支持虚拟化、containerd集成kata运行时、集群存在名为kata的runtimeclass对象。

直接在Pod定义中设置 runtimeClassName: kata 即可让高危应用自动调度到Kata Containers沙箱环境，前提是集群已预先配置好RuntimeClass资源和底层Kata运行时。这不是“一键部署”的魔法，而是声明式调度的精准落地——关键在前期准备是否到位。

前提：集群必须已就绪的三项基础

RuntimeClass编排生效的前提不是写个字段就行，而是整个链条要通：

• 宿主机支持虚拟化：CPU开启VT-x/AMD-V，内核加载 kvm_intel 或 kvm_amd 模块（lsmod | grep kvm 可验证）
• 容器运行时已集成Kata：containerd 配置中已注册 io.containerd.kata.v2 运行时类型，并指向 Kata 配置文件（如 /usr/share/defaults/kata-containers/configuration.toml）
• Kubernetes中存在名为kata的RuntimeClass对象：需手动创建，不能缺失。示例如下：

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: kata
handler: kata
# 可选：指定nodeSelector限制只跑在装了Kata的节点上
scheduling:
  nodeSelector:
    container-runtime: kata

Pod级指派：两行代码完成沙箱绑定

在部署高危应用的YAML中，仅需在 spec 层级添加两行：

spec:
  runtimeClassName: kata
  containers:
  - name: risky-app
    image: registry.example.com/banking-processor:v2.1

此时Kubelet收到该Pod后，会主动查找具备 handler: kata 能力的节点；若节点满足条件（已安装Kata、containerd已配置、标签匹配），则调用 io.containerd.kata.v2 启动轻量VM，而非默认的 runc。整个过程对应用完全透明——无需改代码、不重打包、不调整镜像。

生产环境必须加的三道保险

仅靠 runtimeClassName 不足以应对真实风险，建议同步启用：

• 节点亲和性 + 标签隔离：给装了Kata的节点打标（如 kubectl label nodes node-01 container-runtime=kata），并在RuntimeClass中通过 scheduling.nodeSelector 强制绑定，避免误调度到普通节点
• Pod安全策略（或PodSecurity admission）：禁止特权模式、禁用 hostPath 挂载、强制 readOnlyRootFilesystem: true，防止沙箱内二次逃逸
• seccomp + AppArmor profile：即使在Kata沙箱里，也应叠加用户态系统调用过滤。Kata本身不替代这些机制，而是与之协同增强纵深防御

验证是否真正进入沙箱

部署后快速确认是否生效，避免“以为进了沙箱，实则还在runc”：

• 查看Pod事件：kubectl describe pod <name> | grep -i runtime</name>，输出应含 ContainerRuntime: kata
• 登录对应节点，执行：sudo kata-runtime list，确认该Pod的sandbox ID出现在列表中
• 检查容器进程树：ps auxf | grep -A5 -B5 "qemu\|firecracker"，能看到Kata启动的VMM进程，即为成功