【运维实战】解决 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 配置，适用于限制场景，是生产环境中一个高效可靠的实战技巧。