[Go] containerd：Kubernetes 背后的容器运行时引擎

你知道吗？ 每天数百万个容器在 Kubernetes 集群中启动，但真正负责启动它们的并不是 K8s 本身，而是一个叫 containerd 的"幕后英雄"。作为云原生基础设施的核心组件，它默默支撑着全球大部分容器化应用的运行。

containerd：Kubernetes 背后的容器运行时引擎

高级运维工程师的打怪升级之路 Docker+K8s+Jenkins企业级部署精讲

---

一、containerd 是什么？

containerd 是 CNCF（云原生计算基金会）毕业的工业级容器运行时，专注于一件事：管理容器的完整生命周期。

打个比方：

• Docker 是个功能齐全的工具箱（包含构建、网络、编排等）
• containerd 是工具箱里的核心发动机
• Kubernetes 直接调用这个发动机，跳过工具箱的冗余部分

2016 年 Docker 公司将其核心运行时剥离并捐给 CNCF，成就了今天云原生生态的标准底座。目前它已成为 Kubernetes 的默认容器运行时，也是 云原生技术栈 中不可或缺的基础组件。

---

二、运维工程师为什么要关心它？

场景 1：Kubernetes 集群故障排查

# Pod 起不来？直接看 containerd 日志
journalctl -u containerd -f

# 检查容器运行状态
crictl ps  # 通过 CRI 接口查看
ctr -n k8s.io containers ls  # 直接查 containerd

云栈社区的 SRE 实践表明：60% 的容器问题根源在运行时层，掌握 containerd 能快速定位镜像拉取失败、存储驱动异常等问题。

场景 2：多运行时混合部署

生产环境常见需求：

• 普通业务用 runc（性能最优）
• 金融核心用 Kata Containers（虚拟化隔离）
• AI 训练用 gVisor（安全沙箱）

containerd 的插件架构天然支持这种混合模式：

# /etc/containerd/config.toml
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes]
  [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
    runtime_type = "io.containerd.runc.v2"
  [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata]
    runtime_type = "io.containerd.kata.v2"

场景 3：零停机升级

传统 Docker 升级需要重启所有容器，containerd 通过 shim 进程解耦实现：

containerd 守护进程 → shim 进程 → 容器进程

升级 containerd 时，shim 继续守护容器，业务无感知。

---

三、核心技术架构

分层设计

Kubernetes/Docker
      ↓ (CRI/API)
  containerd (gRPC)
      ↓
containerd-shim (解耦层)
      ↓
   runc (OCI 标准)
      ↓
 Linux Namespace/Cgroup

三大核心能力

镜像管理

• 内容寻址存储（CAS）：相同层只存一份
• 并行下载：HTTP/2 多路复用加速
• 支持 OCI/Docker 双标准

快照系统

• overlayfs：生产环境默认选择
• btrfs/zfs：高级特性（快照回滚）
• native：Windows 容器支持

任务调度

• 容器暂停/恢复
• Checkpoint/Restore（容器迁移）
• 资源限制（CPU/内存/IO）

插件化设计

所有功能都是插件，按需加载：

• Snapshotter 插件：文件系统驱动
• Runtime 插件：容器运行时
• CRI 插件：Kubernetes 集成
• Proxy 插件：远程调用

---

四、实战工具对比

ctr：调试利器

# 拉取镜像
ctr images pull docker.io/library/nginx:alpine

# 运行容器
ctr run -d docker.io/library/nginx:alpine web

# 查看快照
ctr snapshots ls

nerdctl：生产推荐

兼容 Docker 命令习惯：

# Docker 风格操作
nerdctl run -d -p 80:80 nginx:alpine

# 支持 Compose
nerdctl compose up -d

# 镜像加密（企业特性）
nerdctl image encrypt myapp:v1

---

五、性能数据

对比项	containerd	Docker
守护进程内存	10MB	50MB
容器启动延迟	80ms	180ms
镜像拉取速度	并行层下载	串行

测试表明：1000 节点集群使用 containerd 比 Docker 节省 15% 内存开销。

---

六、运维最佳实践

配置优化

# 限制并发拉取数
[plugins."io.containerd.grpc.v1.cri".registry]
  config_path = "/etc/containerd/certs.d"

# 启用镜像加速
[plugins."io.containerd.grpc.v1.cri".registry.mirrors]
  [plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
    endpoint = ["https://mirror.aliyuncs.com"]

监控指标

# Prometheus 指标
curl http://localhost:1338/v1/metrics

# 关键指标
- containerd_container_count
- containerd_task_count
- containerd_image_pull_duration_seconds

日志收集

# 结构化日志输出
containerd --log-level debug --log-format json

---

七、总结

containerd 是云原生基础设施的隐形基石，它不追求大而全，而是专注把容器运行时做到极致。对于 运维工程师 来说：

✅ 必须掌握：Kubernetes 生产环境标配
✅ 性能优势：资源占用低、启动速度快
✅ 扩展性强：插件化架构适配多场景  

下次 Pod 出问题，别只看 kubectl，深入 containerd 层才能找到真相。想系统学习更多 DevOps 技术，欢迎加入云栈社区一起交流。

---

关注《云栈运维云原生》，让系统永不宕机，让部署一键完成！

---

标签： #containerd #Github #Kubernetes #容器运行时 #CNCF #云原生 #DevOps

---

Github仓库： containerd/containerd

官方文档： containerd.io/docs

Docker容器化全面教程： https://yunpan.plus/t/649