Kubeadm初始化踩坑记containerd默认禁用CRI的快速修复方案当你在使用Kubeadm初始化Kubernetes集群时可能会遇到一个令人困惑的错误container runtime is not running。这个错误通常发生在使用containerd作为容器运行时接口(CRI)的情况下。本文将深入分析这个问题的根源并提供详细的解决方案帮助你快速恢复集群初始化流程。1. 问题现象与初步诊断执行kubeadm init命令时最常见的错误输出如下[ERROR CRI]: container runtime is not running: output: time2023-10-26T23:50:43-04:00 levelfatal msgvalidate 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 containerd6.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配置避免了手动操作可能带来的错误。