Kubeadm初始化踩坑记：containerd默认禁用CRI的快速修复方案
Kubeadm初始化踩坑记：containerd默认禁用CRI的快速修复方案
当你在使用Kubeadm初始化Kubernetes集群时，可能会遇到一个令人困惑的错误："container runtime is not running"。这个错误通常发生在使用containerd作为容器运行时接口(CRI)的情况下。本文将深入分析这个问题的根源，并提供详细的解决方案，帮助你快速恢复集群初始化流程。
1. 问题现象与初步诊断
执行kubeadm init命令时，最常见的错误输出如下：
[ERROR CRI]: container runtime is not running: output: time="2023-10-26T23:50:43-04:00" level=fatal msg="validate service connection: validate CRI v1 runtime API for endpoint \"unix:///var/run/containerd/containerd.sock\": rpc error: code = Unimplemented desc = unknown service runtime.v1.RuntimeService" , error: exit status 1这个错误表明Kubeadm无法通过CRI与containerd通信。要验证containerd是否正常运行，可以执行以下命令：
systemctl status containerd如果服务正常运行但依然报错，那么很可能是containerd的CRI插件被禁用了。这是许多Linux发行版中containerd的默认配置。
2. 深入理解问题根源
containerd作为容器运行时，通过CRI插件提供Kubernetes所需的接口。默认安装时，许多发行版会在/etc/containerd/config.toml配置文件中包含以下设置：
disabled_plugins = ["cri"]这种配置会导致containerd不暴露CRI接口，从而使得Kubeadm无法与其通信。这种情况常见于：
- 从发行版仓库直接安装的containerd
- 某些容器优化操作系统的默认配置
- 特定版本的containerd安装包
3. 详细解决方案
3.1 修改containerd配置
首先，我们需要编辑containerd的配置文件：
sudo vi /etc/containerd/config.toml在文件中查找disabled_plugins项，通常会看到类似这样的内容：
disabled_plugins = ["cri"]将其修改为：
disabled_plugins = []如果文件不存在或为空，可以创建以下完整配置：
version = 2 [plugins] [plugins."io.containerd.grpc.v1.cri"] [plugins."io.containerd.grpc.v1.cri".containerd] default_runtime_name = "runc" [plugins."io.containerd.grpc.v1.cri".containerd.runtimes] [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc] runtime_type = "io.containerd.runc.v2"提示：如果使用vim编辑器，可以使用
/disabled_plugins快速搜索目标配置项。
3.2 重启containerd服务
配置修改后，需要重启containerd服务使更改生效：
sudo systemctl restart containerd验证服务状态：
sudo systemctl status containerd3.3 验证CRI接口可用性
可以通过以下命令验证CRI接口是否正常工作：
sudo crictl version正常输出应该类似于：
Version: 0.1.0 RuntimeName: containerd RuntimeVersion: 1.6.8 RuntimeApiVersion: v1alpha24. 重新初始化Kubernetes集群
确认containerd正常运行后，可以重新尝试初始化Kubernetes集群：
sudo kubeadm init如果之前已经尝试过初始化，可能需要先重置环境：
sudo kubeadm reset5. 高级配置与优化
5.1 配置crictl使用正确的端点
确保/etc/crictl.yaml包含正确的containerd socket路径：
runtime-endpoint: unix:///var/run/containerd/containerd.sock image-endpoint: unix:///var/run/containerd/containerd.sock timeout: 10 debug: false5.2 配置容器镜像加速器
在国内环境，可以配置镜像加速器提升拉取镜像速度。在/etc/containerd/config.toml中添加：
[plugins."io.containerd.grpc.v1.cri".registry.mirrors] [plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"] endpoint = ["https://registry-1.docker.io"]5.3 配置日志和存储选项
根据需求调整日志和存储设置：
[plugins."io.containerd.grpc.v1.cri".containerd] snapshotter = "overlayfs" [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options] SystemdCgroup = true6. 常见问题排查
6.1 修改配置后服务无法启动
如果修改配置后containerd无法启动，可以尝试：
- 检查配置文件语法：
containerd config dump > /tmp/default-config.toml diff /etc/containerd/config.toml /tmp/default-config.toml - 查看详细日志：
journalctl -xeu containerd
6.2 Kubeadm初始化仍然失败
如果问题依旧，可以尝试：
- 检查Kubelet日志：
journalctl -xeu kubelet - 验证Kubelet配置：
cat /var/lib/kubelet/config.yaml - 确保没有残留的CNI配置：
rm -rf /etc/cni/net.d/*
7. 最佳实践与经验分享
在实际生产环境中，我建议采用以下部署流程：
- 先安装并配置containerd，验证CRI接口可用性
- 安装kubeadm、kubelet和kubectl
- 初始化集群前，确保所有节点时间同步
- 对于多节点集群，先在主节点初始化，再添加工作节点
一个实用的检查清单：
- [ ] containerd服务正常运行
- [ ] CRI插件已启用
- [ ] crictl可以正常与containerd通信
- [ ] 防火墙规则允许必要的通信
- [ ] 系统资源满足Kubernetes最低要求
在最近的一个项目中，我们发现某些云厂商的镜像会默认禁用CRI插件。通过编写自动化配置脚本，我们确保了每次部署时都会检查并正确设置containerd配置，避免了手动操作可能带来的错误。