3. 主流 CRI 实现对比：containerd、CRI-O、Docker Engine（已弃用）的架构与安全特性对比
Kubernetes 通过 CRI（Container Runtime Interface）屏蔽了底层容器运行时的差异。在集群节点扩容场景中，运行时选型直接影响节点初始化速度、资源开销以及安全基线的建立。本章对三种主流 CRI 实现——containerd、CRI-O 以及已弃用的 Docker Engine——进行架构与安全特性的系统性对比。
3.1 架构演进与弃用背景
Kubernetes 在 v1.24 版本中正式移除对 Docker Engine 的内建支持（dockershim）。Docker Engine 并非原生实现 CRI，而是通过 dockershim 适配层桥接，导致调用链冗长、故障域扩大。containerd 和 CRI-O 均原生实现 CRI，架构更简洁，已成为社区推荐的生产级运行时。
关键结论： 新集群节点扩容应优先选用 containerd 或 CRI-O；Docker Engine 仅适用于存量集群迁移过渡期，不建议用于新建节点。
3.2 核心安全特性对比
在节点扩容场景中，运行时安全特性直接影响集群的纵深防御能力。以下从六个维度进行对比：
| 安全维度 | containerd | CRI-O | Docker Engine（已弃用） |
|---|---|---|---|
| 默认 Seccomp 策略 | 支持，需手动配置 | 支持，默认启用运行时默认策略 | 支持，需手动配置 |
| AppArmor / SELinux | 支持，通过 OCI 注解传递 | 原生支持，与节点策略深度集成 | 支持，但需额外配置 |
| 只读根文件系统 | 支持 | 支持 | 支持 |
| 用户命名空间支持 | 支持（Kubernetes v1.25+） | 支持（Kubernetes v1.25+） | 支持，但需 dockershim 适配 |
| 镜像签名验证 | 需集成外部工具（如 Notary） | 内建支持（通过 containers/image） | 需集成 Docker Content Trust |
| 最小化攻击面 | 守护进程功能精简，攻击面小 | 专为 Kubernetes 设计，攻击面最小 | 包含大量非 CRI 功能，攻击面最大 |
安全选型建议： 在节点扩容时，若对安全基线要求较高（如金融、政务场景），CRI-O 的默认安全策略和镜像验证内建支持更具优势；containerd 则在性能与功能灵活性上表现均衡，适合大多数通用场景。
3.3 节点扩容场景下的安全配置差异
节点加入集群时，kubelet 通过 CRI 接口与运行时交互。不同运行时的安全配置入口存在差异：
- containerd： 配置文件位于
/etc/containerd/config.toml，需在[plugins."io.containerd.grpc.v1.cri".containerd]段中设置discard_unpacked_layers、default_runtime等安全参数。 - CRI-O： 配置文件位于
/etc/crio/crio.conf，支持seccomp_profile、apparmor_profile等全局安全默认值，节点初始化时自动加载。 - Docker Engine： 需同时配置
/etc/docker/daemon.json和 dockershim 参数，配置分散且易遗漏。
3.4 生产环境选型建议
综合架构简洁性、安全特性与社区支持，给出以下选型建议：
推荐优先级： CRI-O ≥ containerd >> Docker Engine（已弃用）
- CRI-O： 适合安全合规要求严格的场景（如金融、政府、医疗），其默认安全策略和镜像验证内建支持可减少人工配置失误。
- containerd： 适合通用生产环境，性能优异，社区生态成熟，与 Kubernetes 集成度高。
- Docker Engine： 仅建议在存量集群迁移过渡期使用，新节点扩容不应再选用。
安全警告： 在节点扩容时，务必检查运行时的安全配置是否与集群 Pod Security Standards（PSS）一致。使用 Docker Engine 时，需额外验证 dockershim 是否已正确传递 Seccomp 和 AppArmor 策略，否则可能导致安全策略失效。