【运维实战】解决 K8s 节点无法拉取 pause:3.6 镜像导致 API Server 启动失败的问题
目录
【运维实战】解决 K8s 节点无法拉取 pause:3.6 镜像导致 API Server 启动失败的问题
🔍 问题分析
✅ 解决方案:替代拉取方式导入 pause 镜像
Step 1. 从私有仓库拉取 pause 镜像
Step 2. 重新打 tag 为 Kubernetes 默认命名
Step 3. 导出镜像为 tar 包
Step 4. 拷贝镜像到目标节点
Step 5. 在目标节点导入镜像到 containerd 的 k8s.io 命名空间
Step 6. 验证镜像是否导入成功
📌 注意事项
📎 总结
【运维实战】解决 K8s 节点无法拉取 pause:3.6 镜像导致 API Server 启动失败的问题
在使用 Kubernetes 部署集群过程中,控制面组件 kube-apiserver
启动失败,多个节点处于 NotReady
状态。查看 kubelet 日志发现如下错误:
failed to get sandbox image "registry.k8s.io/pause:3.6": failed to pull image ...
dial tcp 173.194.202.82:443: i/o timeout
这说明节点无法从默认的 registry.k8s.io
拉取 pause:3.6
镜像,直接导致 Pod Sandbox 创建失败,从而影响整个控制平面组件运行。
🔍 问题分析
Kubernetes 默认使用 pause:3.6
镜像作为 Pod 的基础运行环境容器(Pod Sandbox),当节点访问公网受限或 GFW 屏蔽时,将无法拉取该镜像,导致所有 Pod 无法启动。
尽管可以通过修改 kubelet
的 sandboxImage
参数绕过此问题,但某些环境中限制修改 kubelet 配置或容器运行时行为。因此本文采用 镜像替换 + 标准命名空间导入 的方式解决此问题。
✅ 解决方案:替代拉取方式导入 pause 镜像
我们通过手动拉取私有仓库中的 pause 镜像,并转换为标准命名,导入 containerd 默认命名空间,解决拉取失败问题。
Step 1. 从私有仓库拉取 pause 镜像
docker pull 10.130.135.145:30500/pause:3.6
Step 2. 重新打 tag 为 Kubernetes 默认命名
docker tag 10.130.135.145:30500/pause:3.6 registry.k8s.io/pause:3.6
Step 3. 导出镜像为 tar 包
docker save -o pause-3.6.tar registry.k8s.io/pause:3.6
Step 4. 拷贝镜像到目标节点
scp pause-3.6.tar root@<node-ip>:/tmp/
Step 5. 在目标节点导入镜像到 containerd 的 k8s.io
命名空间
sudo ctr -n k8s.io images import /tmp/pause-3.6.tar
Step 6. 验证镜像是否导入成功
sudo ctr -n k8s.io images ls | grep "pause:3.6"
输出如下表示成功:
registry.k8s.io/pause:3.6 ... linux/amd64
📌 注意事项
-
若使用
containerd
,请确保命令中使用了-n k8s.io
命名空间; -
若使用的是
crictl
工具,也可使用crictl pull registry.k8s.io/pause:3.6
进行验证; -
pause
镜像是所有 Pod 的基础容器,缺失将影响整个集群功能; -
建议在所有节点均完成此操作。
📎 总结
通过将 pause:3.6
镜像从私有仓库拉取并导入到 Kubernetes 标准命名,成功绕过公网拉取失败问题。这种方法无需修改 kubelet 配置,适用于限制场景,是生产环境中一个高效可靠的实战技巧。