kubernetes弃用docker主因是其不原生支持cri标准，需依赖维护成本高的dockershim适配层；而runtimeclass作为k8s调度层特性，依赖cri和kubelet运行时感知机制，docker engine未实现cri，故无法支持runtimeclass。
RuntimeClass 是 Kubernetes 的能力，Docker 本身不支持 RuntimeClass。你无法在纯 Docker 环境中配置 RuntimeClass 来启用 Kata Containers。
为什么 Docker 不支持 RuntimeClass
RuntimeClass 是 Kubernetes v1.12 引入的 API 对象，专用于 K8s 调度层对 Pod 运行时的声明式选择。它依赖于 CRI（Container Runtime Interface）接口和 kubelet 的运行时感知机制。而 Docker Engine（尤其是已停止维护的 dockerd）不实现 CRI，也不具备识别或处理 runtimeClassName 字段的能力。
Docker CLI（如 docker run）可通过 --runtime 参数直接指定运行时（例如 --runtime=kata），但这属于运行时手动切换，与 RuntimeClass 的集群级策略、节点自动匹配、Pod 级别调度绑定等能力完全无关。
想用 Kata 实现硬件级强隔离，正确路径是 Kubernetes + CRI 运行时
要真正发挥 Kata Containers 的硬件隔离优势，并结合 RuntimeClass 做精细化管控，必须使用符合 CRI 的容器运行时（如 containerd 或 CRI-O），并部署在 Kubernetes 集群中：
- 在宿主机上安装 Kata Containers 并验证其可运行（
kata-runtime kata-check） - 配置 containerd：在
/etc/containerd/config.toml中添加 kata 运行时插件，指定runtime_type = "io.containerd.kata.v2" - 创建 RuntimeClass 对象，例如名为
kata-clh，关联到 containerd 中定义的 kata 运行时名称 - 在 Pod YAML 中设置
runtimeClassName: kata-clh，kubelet 会据此调度到装有 Kata 的节点，并由 containerd 调用 kata 启动轻量虚拟机
如果坚持只用 Docker，替代方案有限但可行
虽然不能用 RuntimeClass，但 Docker 可以直连 Kata 作为替代运行时：
- 确保 Docker 已配置为使用 containerd 作为底层运行时（Docker 20.10+ 默认如此）
- 在 containerd 配置中注册 kata 运行时（同上）
- 执行
docker run --runtime=io.containerd.kata.v2 -it ubuntu bash - 该命令会绕过 runc，由 containerd 启动 Kata MicroVM，实现单容器的硬件隔离
- 注意：此方式无节点筛选、无资源配额联动、无健康检查集成，仅适合测试或边缘场景
关键提醒：隔离效果取决于实际运行时行为
无论是否通过 K8s，只要容器进程最终由 Kata 启动（即进入独立内核的 MicroVM），就获得硬件级隔离——包括独立内存空间、vCPU、设备视图和 guest 内核。但以下几点决定实际安全水位：
- 宿主机 BIOS 中必须开启 VT-x / AMD-V，且未被其他 hypervisor（如 VirtualBox）独占
- Kata 镜像需使用精简内核（如
vmlinuz.container）和最小 initrd，避免引入攻击面 - 网络需通过 CNI 插件（如 Calico）配合 Kata 的 netns 支持，防止虚拟网卡桥接导致侧信道泄露
- 若需更高保障，应启用 TEE 支持（如 Intel SGX），这需要 Kata + kernel + workload 全栈适配
