Ubuntu环境下Kubernetes集群容器运行时从Docker迁移至Containerd全指南

引言

在Kubernetes生态中，容器运行时的选择直接影响集群的性能、安全性和可维护性。随着Kubernetes社区逐步弃用Docker作为默认运行时（自Kubernetes v1.24起移除dockershim），迁移到Containerd成为必然选择。本文将详细阐述在Ubuntu环境中，如何将已有的Kubernetes集群容器运行时从Docker平滑迁移至Containerd，涵盖技术背景、操作步骤、原理解析及验证方法。

技术背景

1. Docker与Containerd对比

2. 迁移必要性

• ​​兼容性​​：Kubernetes v1.24+不再支持dockershim。
• ​​性能优化​​：Containerd直接与Kubelet交互，减少中间层开销。
• ​​安全性​​：更小的攻击面，符合云原生安全标准。

应用使用场景

1. ​​生产环境升级​​：满足Kubernetes版本迭代需求。
2. ​​资源优化​​：降低节点资源消耗，提升集群密度。
3. ​​合规要求​​：满足金融/政府等行业对轻量级运行时的规范。

原理解释与核心特性

迁移核心原理

1. ​​CRI（Container Runtime Interface）标准化​​：
   • Containerd通过cri-plugin直接实现CRI接口，Kubelet无需dockershim适配层。
2. ​​镜像管理兼容​​：
   • Containerd复用Docker的镜像存储路径（/var/lib/docker），避免镜像重新拉取。
3. ​​网络插件适配​​：
   • CNI插件（如Calico、Flannel）无需变更，保持原有网络策略。

核心特性对比表

环境准备

1. 系统要求

• Ubuntu 20.04 LTS（已验证）
• Kubernetes v1.24+（示例版本：v1.26.3）
• Containerd v1.6+（示例版本：v1.6.18）
• 已存在的Kubernetes集群（Docker运行时）

2. 节点规划

详细迁移步骤

阶段一：准备工作（所有节点）

1. 备份关键数据

# 备份Docker镜像
sudo docker images --format '{{.Repository}}:{{.Tag}}' | xargs -I {} sudo docker save {} > /backup/docker-images-$(date +%F).tar

# 备份Kubernetes配置
sudo cp -r /etc/kubernetes /backup/kubernetes-config
sudo cp -r /var/lib/kubelet /backup/kubelet-data

2. 安装Containerd

# 添加apt密钥和源
sudo apt-get update && sudo apt-get install -y apt-transport-https ca-certificates curl gnupg
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# 安装Containerd
sudo apt-get update && sudo apt-get install -y containerd.io=1.6.18-1

# 配置Containerd
sudo mkdir -p /etc/containerd
sudo containerd config default | sudo tee /etc/containerd/config.toml

# 修改配置：启用CRI和镜像仓库镜像（可选）
sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml
sudo sed -i '/$$plugins."io.containerd.grpc.v1.cri".registry.mirrors$$/a \    [plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]\n      endpoint = ["https://registry-1.docker.io"]' /etc/containerd/config.toml

# 重启Containerd
sudo systemctl restart containerd
sudo systemctl enable containerd

阶段二：Kubelet配置修改（所有节点）

1. 修改Kubelet配置

# 编辑Kubelet配置文件
sudo vim /etc/default/kubelet

# 添加以下内容（若已存在则修改）
KUBELET_EXTRA_ARGS="--container-runtime=remote --container-runtime-endpoint=unix:///run/containerd/containerd.sock"

2. 重启Kubelet

sudo systemctl daemon-reload
sudo systemctl restart kubelet

阶段三：验证与清理（所有节点）

1. 验证Containerd集成

# 检查Kubelet状态
sudo systemctl status kubelet

# 查看CRI接口响应
sudo crictl version
# 预期输出：
# Version:  0.2.0
# RuntimeName:  containerd
# RuntimeVersion:  v1.6.18
# RuntimeApiVersion:  v1alpha2

2. 清理Docker残留（可选）

# 停止Docker服务
sudo systemctl stop docker
sudo systemctl disable docker

# 卸载Docker（保留镜像数据）
sudo apt-get purge docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo rm -rf /var/lib/docker  # 谨慎操作！确保已备份镜像

测试验证

1. 集群状态检查

# 检查节点状态
kubectl get nodes -o wide
# 预期状态：所有节点 Ready

# 检查Pod运行情况
kubectl get pods --all-namespaces
# 预期：所有Pod处于 Running 状态

2. 新Pod创建测试

# 部署测试Pod
kubectl run nginx-test --image=nginx:latest --restart=Never

# 验证Pod运行
kubectl get pods
kubectl describe pod nginx-test | grep -i containerd
# 预期：看到容器由containerd管理

疑难解答

1. Kubelet无法启动

• ​​错误日志​​：Failed to create CRI client: failed to load CRI config
• ​​解决方案​​：

  # 检查配置文件语法
  sudo cri-tools validate /etc/containerd/config.toml
  
  # 确认CRI socket路径
  sudo ls -l /run/containerd/containerd.sock

2. 镜像拉取失败

• ​​错误现象​​：Failed to pull image "nginx:latest": rpc error: code = Unknown desc = failed to pull and unpack image
• ​​解决方案​​：

  # 检查Containerd镜像列表
  sudo crictl images
  
  # 手动拉取镜像
  sudo ctr -n k8s.io image pull docker.io/library/nginx:latest

未来展望与技术趋势

1. Kubernetes运行时演进

• ​​CRI-O​​：Red Hat主导的轻量级运行时，更适合OpenShift生态。
• ​​Kata Containers​​：安全容器运行时，提供虚拟机级隔离。

2. 混合云原生架构

• ​​Serverless容器​​：如Knative，进一步抽象运行时管理。
• ​​边缘计算​​：轻量化运行时（如WasmEdge）支持边缘场景。

总结

通过本文的实践，我们完成了以下目标：

1. ​​平滑迁移​​：在不影响业务Pod的情况下切换运行时。
2. ​​性能优化​​：Containerd的轻量化特性提升集群资源利用率。
3. ​​未来兼容​​：符合Kubernetes长期支持路线图。

​​后续建议​​：

• 监控节点资源使用变化（kubectl top nodes）。
• 逐步替换节点以降低风险（滚动升级策略）。
• 评估镜像仓库性能（Containerd默认无本地缓存优化）。