【笔记】cri-docker.service和containerd

cri-docker.service 和 containerd 都是 Kubernetes 支持的容器运行时组件，但它们的架构、功能定位及与 Docker 的关系有显著差异。以下是它们的核心区别和关联：

---

1. 功能定位

组件	核心角色	是否直接支持 CRI
containerd	轻量级容器运行时，直接管理容器的生命周期（创建、启动、停止等），是 Docker 的底层引擎。	是（内置 CRI 插件）
cri-docker.service	适配器服务，将 Kubernetes 的 CRI 请求转换为 Docker API，使 Kubelet 能通过 Docker 管理容器。	否（需转换协议）

---

2. 架构差异

containerd 的架构

• 直接路径：
  Kubelet 通过 CRI 直接调用 containerd，containerd 使用 runc 创建容器。
  无 Docker 参与，性能更高，路径更短。

cri-docker.service 的架构

• 间接路径：
  Kubelet 的 CRI 请求需经 cri-docker 转换为 Docker API，再由 dockerd 调用 containerd。
  多一层转换，依赖 Docker 的完整堆栈。

---

3. 与 Docker 的关系

组件	是否依赖 Docker	能否脱离 Docker 独立运行
containerd	否	是（Docker 底层使用它，但可独立运行）
cri-docker.service	是	否（必须安装 Docker）

• 关键区别：
  • containerd 是 Docker 的底层组件，但完全独立，可直接被 Kubernetes 使用。
  • cri-docker.service 是 Docker 的“兼容层”，目的是让 Kubernetes 继续调用 Docker。

---

4. 性能与复杂度

维度	containerd	cri-docker.service
性能	更高（直接 CRI 调用，无额外转换）	较低（CRI → Docker API → containerd）
组件复杂度	轻量（仅核心运行时功能）	较重（依赖 Docker 完整堆栈）
调试难度	简单（日志和路径清晰）	复杂（需排查多层级调用）

---

5. 使用场景对比

场景	推荐方案	原因
生产环境（Kubernetes ≥1.24）	containerd 或 CRI-O	原生支持 CRI，性能优，维护成本低。
开发/测试环境（依赖 Docker）	cri-docker.service	兼容现有 Docker 工具链（如 docker build、docker logs）。
从 Docker 迁移到原生 CRI	过渡期使用 cri-docker	逐步迁移业务到 containerd，避免一次性改动。

---

6. 如何选择？

• 优先 containerd：
  如果不需要 Docker 特定功能（如 docker compose），直接使用 containerd 是 Kubernetes 的推荐方案。
• 不得已用 cri-docker：
  仅当强依赖 Docker 生态时使用（例如某些 CI/CD 工具链）。

---

7. 命令示例：查看运行时

检查当前运行时

# 查看 containerd 是否运行
systemctl status containerd

# 查看 cri-docker 是否运行
systemctl status cri-docker

查看 Kubelet 使用的运行时

ps -ef | grep kubelet | grep -- --container-runtime
# 输出示例：
# --container-runtime=remote --container-runtime-endpoint=unix:///var/run/containerd/containerd.sock
# 或
# --container-runtime-endpoint=unix:///var/run/cri-dockerd.sock

---

总结

• containerd：
  Kubernetes 生产级运行时，直接、高效，是 Docker 的底层但可独立运行。
• cri-docker.service：
  为兼容 Docker 存在的过渡方案，通过协议转换实现 CRI 支持，性能较低但保留 Docker 工具链。
• 关系：
  cri-docker 依赖 Docker，而 Docker 依赖 containerd；若无需 Docker，应直接使用 containerd。