问题描述

最近实战时，发现一个很奇怪的问题，在通过 k8s 创建 pod，拉取镜像时，总是显示如下信息：

Error syncing pod, skipping: failed to "StartContainer" for "POD" with ImagePullBackOff: "Back-off pulling image ..."

原因分析

该现象出现的原因可能是网络问题、docker 环境问题等。但如果访问的是一个公开的镜像仓库，在 pull image 的时候，不应该会提示：ImagePullBackOff，但如果访问的是私有仓库，那就有可能出现如下的错误：

这个错误出现的原因，刚才说了，有可能的网络问题，也有可能是 docker 问题，但有时候，这些不能解决的情况下，可以采用下面三种方式来解决。

解决方案

方式一

第一种方式，我们可以使用文件生成 secret，然后通过 k8s 中的 imagePullSecrets 来解决拉取镜像时的验证问题。具体方式如下：

修改 /etc/docker/daemon.json

在 k8s 集群节点上，修改 docker 的 daemon.json 配置文件：

{"registry-mirrors": [ "https://registry.docker-cn.com"],"insecure-registries":["私有仓库服务地址"]
}

在里面加上自己私有的仓库服务地址，然后重启 docker 服务，使其生效。

生成 ~/.docker/config.json 文件

docker login 私有服务地址

在命令行输入上面的命令，回车后，会提示输入用户名和密码。输入正确信息后，这会生成一个 /root/.docker/config.json 文件。同时会提示：

Login Succeeded

生成 Secret 串

根据上面生成的 ~/.docker/config.json 文件，我们可以生成一个密文秘钥：

base64 -w 0 ~/.docker/config.json

执行上面的命令后，会生成一个长串，即为我们所要的 Secret 串。

我们会在 source 下看见一个新的文件夹，_drafts，这个里面会装我们所有的草稿文件。

创建 Secret

通过 k8s 我们可以生成一个 Secret 资源：

apiVersion: v1
kind: Secret
metadata:name: docker_reg_secretnamespace: default
data:.dockerconfigjson: ewoJImF1dGhjNWdlpHVnVaenB5Wld4aFFFeFdUa2xCVGtBeU1ERTMiCgkJfASEkidXJlZy5rOHMueXVud2VpLnJlbGEubWUiOiB7CgkJCSJhdXRoIjogIloyRnZaM1Z2WkdWdVSrsaaehoUUV4V1RrbEJUa0F5TURFMyIKCQl9Cgl9LAoJIkh0dHBIZWFkZXJzIjogewoJSetcaFTssZW50IjogIkRvY2tlci1DbGllbnQvMTguMDYuMS1jZSAobGludXgpIgoJfQp9
type: kubernetes.io/dockerconfigjson

执行这个资源的配置：

kubectl create -f secret.yml

在服务配置加上依赖

最后，可以在 我们的服务 yml 文件中加上拉取镜像时的依赖 secret，部分代码如下：

imagePullSecrets:
- name: docker_reg_secret

方式二

第二种方式，我们可以直接使用 docker 的用户信息来生成 secret：

kubectl create secret docker-registry docker_reg_secret --docker-server=XXX --docker-username=XXX --docker-password=XXX

参数含义：

• docker_reg_secret：指定密钥的键名称，自定义
• docker-server： 指定docker仓库地址
• docker-username：指定docker仓库账号
• docker-password：指定docker仓库密码

创建完 Secret 资源后，其他的如方式一，这就简单了。

方式三

第三种方式所使用的是最简单的办法，即我们利用 k8s 的拉取镜像的策略来处理，主要有如下三种：

• Always：每次创建时都会拉取镜像
• IfNotPresent：宿主机器不存在时拉取镜像（默认值）
• Never：从不主动拉取镜像

使用 IfNotPresent、Never 策略来处理。

以上三种方式，我比较推荐第二种，最中意第二种，因为假如密码修改了，就更新一下 secret 就好了，k8s node 不需要改动。而第一种需要改动，第三种会导致镜像丢失，毕竟只有本地存在。