线上刚发了一个新版本。
CI构建成功，镜像也已经推到仓库。
开发机上手工执行docker pull，几秒钟就能正常把镜像拉下来。
可Deployment发布到Kubernetes以后，新Pod却迟迟起不来：
NAME READY STATUS RESTARTS order-service-6f7d8b-x2k9p 0/1 ImagePullBackOff 0第一反应通常是：
镜像仓库是不是挂了？
可重新在自己电脑上拉一次：
成功。
Tag也能看到。
甚至同事电脑上同样能拉。
这时候特别容易陷入一个误区：
“我本地都能docker pull，Kubernetes凭什么拉不到？”
真正要先理解的是：
你的电脑能拉镜像，和Kubernetes节点能拉镜像，是两套完全不同的运行环境。
账号不一样。
网络不一样。
DNS不一样。
证书信任不一样。
甚至拉镜像使用的Runtime都可能不一样。
所以遇到ImagePullBackOff，第一步不是继续在开发机反复docker pull。
而是先确认：
出问题的那个Node，到底为什么拉取失败。
一、先给核心判断：ImagePullBackOff不是根因
ImagePullBackOff更像一个结果状态。
Pod需要启动。
Kubelet让Container Runtime去拉镜像。
第一次拉失败。
稍后再试。
继续失败。
Kubernetes开始逐渐延长重试间隔。
最后你在Pod状态里看到：
ImagePullBackOff
所以真正需要找的是：
第一次Image Pull为什么失败。
不是研究“BackOff怎么关闭”。
也不是删Pod让它重新拉。
删掉以后，如果根因没变，新Pod还是会继续失败。
二、第一步直接看Events，通常已经告诉你一半答案
我碰到这种问题，第一动作通常是：
kubectl describe pod <pod-name> -n <namespace>直接拉到最下面看Events。
比如可能看到：
Failed to pull image "registry.example.com/order-service:v2.6": failed to authorize: failed to fetch anonymous token: 401 Unauthorized Error: ErrImagePull Back-off pulling image这时候根本不用继续猜网络。
方向已经非常明确：
认证。
如果看到的是：
manifest unknown
更像镜像名或Tag。
如果是：
x509: certificate signed by unknown authority
重点查证书。
如果是：
i/o timeout
connection refused
no such host
方向又变成网络、DNS或者Registry可达性。
所以：
ImagePullBackOff真正最重要的信息，不在STATUS那一列，而在Events的原始错误里。
三、最常见的第一类问题：你本地已经登录，Kubernetes没有
比如你电脑上以前执行过Registry登录。
Docker本地已经保存了认证信息。
所以：
docker pull registry.example.com/order-service:v2.6
当然成功。
但这些登录凭证只存在你的电脑。
Kubernetes Node不会自动继承。
Pod也不会知道你开发机登录过什么。
如果是私有镜像仓库，通常需要给Pod提供正确的：
imagePullSecrets
或者让对应ServiceAccount携带镜像拉取凭证。
所以很典型的一种现场就是：
开发机正常。
CI也正常。
Kubernetes失败。
因为三边实际上使用的是：
三套不同的Registry Credential。
四、Secret存在，不代表Pod真的用了
这也是特别常见的坑。
你去Namespace里一看：
Registry Secret确实存在。
于是下结论：
凭证肯定没问题。
还不能这么快。
还要继续确认：
这个Pod到底有没有引用它。
有些项目是在Deployment里直接配置。
有些则绑在ServiceAccount上。
甚至还会出现：
Secret建在A Namespace。
Pod实际跑在B Namespace。
名字完全一样，但不是同一个对象。
所以真正应该确认的不是：
“集群里有没有这个Secret”。
而是：
“当前Pod所在Namespace里，它实际使用的拉取凭证是什么。”
这一步一旦错了，Registry就会把Pod当成：
匿名客户端
或者错误账号。
最后就是401、403之类的拉取失败。
五、第二种高频问题：镜像地址或者Tag其实不对
这个看起来很简单，但线上真的非常常见。
比如CI推的是：
registry.example.com/backend/order-service:v2.6.1
Deployment写的是：
registry.example.com/order-service:v2.6.1
少了一层路径。
或者CI刚生成的新Tag是：
20261013-1045
YAML里仍然引用昨天的：
20261012-1810
还有一种更隐蔽：
同一个Tag在不同Registry Project下面都存在。
你本地拉的是A仓库。
Kubernetes YAML实际上指向B仓库。
于是大家一直说：
Tag明明存在。
但看的根本不是同一个位置。
所以排查镜像名称时，不要凭印象。
直接把Pod实际配置里的：
Registry / Repository / Image / Tag
完整拿出来逐段对。
六、第三种情况：Node根本访问不到Registry
假设本地在公司网络里。
能正常访问：
registry.example.com
Kubernetes Node却运行在：
另一个VPC。
另一个子网。
另一套DNS。
甚至通过不同代理出口。
那么“我电脑能拉”几乎证明不了Node网络。
这时候Events如果出现：
连接超时。
DNS失败。
连接被拒绝。
就应该从Node视角继续排。
关键不是：
你浏览器能不能打开Registry。
而是：
实际调度这个Pod的Node，能不能解析并访问Registry地址。
特别是多Node集群里，还可能出现：
Node A可以拉。
Node B拉不到。
于是同一个Deployment有些Pod Running，有些Pod ImagePullBackOff。
这种时候看起来像随机故障，实际上是：
节点网络环境不一致。
七、为什么只有某几个Pod拉不到镜像特别值得注意？
假设副本数是6。
其中4个Pod正常Running。
2个一直ImagePullBackOff。
而且镜像、Secret、Deployment完全一样。
这时候我会马上去看：
这两个失败Pod被调度到了哪些Node。
如果失败始终集中在：
node-7。
node-9。
那问题很可能已经从：
Kubernetes配置
缩小成：
Node级问题。
例如：
节点DNS异常。
到Registry的路由不同。
代理没配置。
CA证书没装。
Container Runtime配置不一致。
这种情况下你继续改Deployment，反而容易把正确配置改坏。
八、第四种典型情况：浏览器信任证书，但Container Runtime不信任
如果使用：
Harbor。
内部Docker Registry。
企业自建镜像仓库。
经常会碰到私有CA证书。
开发电脑已经安装了公司CA。
所以访问Registry完全正常。
但Node上的containerd并没有信任这张CA。
结果拉镜像时出现类似：
x509: certificate signed by unknown authority
这时候问题不是镜像权限。
也不是Tag。
而是：
实际执行Image Pull的Runtime无法验证Registry证书链。
尤其现在很多Kubernetes环境使用containerd，而不是开发机上的Docker。
你在自己电脑修改Docker证书配置，对Node上的containerd没有任何作用。
排查时一定要明确：
究竟是谁在真正拉镜像。
九、第五种情况：账号能登录，但没有这个Repository的Pull权限
认证成功和授权成功是两回事。
比如Registry账号有效。
Secret也没过期。
但这个账号只有：
Project A
的权限。
新镜像却推到了：
Project B。
那么登录行为可能完全正常。
真正Pull某个Repository时才被拒绝。
这时候Events里常见会出现：
Unauthorized。
Denied。
Forbidden。
所以看到权限类错误时，不要只检查：
用户名密码对不对。
还应该继续问：
这个Credential到底有没有目标镜像的Pull权限。
十、还有一种比较容易忽略：镜像平台不匹配
现在开发机是Apple Silicon、ARM服务器、多架构Kubernetes以后，这类问题越来越容易出现。
例如CI只推了：
linux/amd64
镜像。
Pod却被调度到：
arm64
节点。
或者反过来。
Registry里Tag确实存在。
认证也完全正确。
但Runtime找不到适合当前节点平台的Manifest。
这时候就不是：
“镜像不存在”。
而是：
这个Tag下面没有当前Node能运行的镜像架构。
如果集群里同时存在amd64和arm64节点，就更容易出现：
部分Node正常，部分Node失败。
所以需要看：
镜像Manifest。
Node Architecture。
构建平台
是不是一致。
十一、imagePullPolicy也要看，但别把它当万能答案
常见拉取策略比如：
Always
IfNotPresent
不同策略会影响Kubelet什么时候重新拉镜像。
比如使用固定Tag，又持续覆盖同一个镜像时，拉取策略就会影响最终拿到哪个版本。
但如果Events已经明确告诉你：
401。
DNS超时。
x509。
manifest不存在。
那修改imagePullPolicy并不会真正解决问题。
所以不要看到ImagePullBackOff就机械地：
Always改成IfNotPresent
或者反过来。
还是那句话：
先看原始失败原因，再决定改什么。
十二、我更推荐按这条顺序排
以后再碰到：
本地docker pull正常，但Kubernetes ImagePullBackOff
可以直接记住这条链：
Events → Image/Tag → Secret → Registry权限 → Node网络/DNS → CA证书 → Runtime/平台
先让Events帮你定大方向。
如果401，就别先查DNS。
如果x509，就别一直重建Secret。
如果no such host，就先解决Node解析。
如果只有某几个Node失败，就先比较Node环境。
这样排查速度会比“把所有配置都检查一遍”快很多。
十三、为什么反复删除Pod经常会制造“玄学恢复”？
因为重新创建Pod以后，它可能被调度到了另一台Node。
假设：
node-1 Registry网络正常。
node-2 Registry网络有问题。
第一次Pod在node-2：
ImagePullBackOff。
你删掉。
新Pod碰巧跑到node-1：
成功Running。
于是大家以为：
删除Pod解决了。
其实什么都没修。
真正发生的只是：
Pod换了一个没有故障的Node。
下一次调度回node-2，问题还会重新出现。
所以“删Pod以后恢复”本身也是一个Evidence。
不要把它直接当成修复动作。
十四、还有一种坑：CI推镜像成功，不代表生产集群能访问同一个地址
有些公司CI系统通过内部地址推镜像。
例如：
Registry内网域名。
而生产集群使用的是：
另一个域名。
或者需要经过代理。
如果部署模板把CI侧镜像地址原封不动带进生产，Node就可能根本访问不了。
所以完整链路应该确认：
Build能Push的地址，是否也是Runtime能够Pull的地址。
这是两个方向完全不同的网络路径。
十五、修完以后怎么验证？
不要只看：
Pod终于Running。
至少再确认三件事。
第一，重新创建Pod还能不能稳定拉下来。
第二，如果是多Node集群，换几个不同Node以后是不是都正常。
第三，下一次镜像版本更新以后是不是仍然可以Pull。
如果问题来自：
Secret。
Node CA。
Registry权限。
DNS。
平台架构，
都应该验证对应场景真正恢复。
比如之前只有arm64节点失败，就必须让Pod重新调度到arm64节点验证。
否则只是绕过了问题。
十六、ChatGPT、Codex在这种问题里怎么用更有效？
不要只告诉ChatGPT、Codex：
Kubernetes ImagePullBackOff怎么解决？
最好一起给：
Pod Events。
完整Image地址。
Namespace。
Deployment里的Image配置。
imagePullSecrets。
ServiceAccount。
失败Pod所在Node。
Registry类型。
是否只有部分Node失败。
这样AI才能很快把问题分成：
认证。
授权。
Tag。
DNS。
网络。
CA。
Runtime
几个方向。
如果Helm Chart、Deployment YAML就在仓库里，Codex还可以继续检查：
Secret到底有没有绑定。
镜像地址从哪一个Values覆盖进来的。
新版本是不是引用错了Tag。
这种问题里，AI最有价值的地方不是背一堆kubectl命令。
而是：
把Pod配置、Registry和Node环境拼成一条完整拉取链路。
十七、Plus和Pro怎么判断？
如果你只是偶尔让ChatGPT、Codex：
分析一个ImagePullBackOff。
检查Pod Events。
看一份Deployment。
排一个Registry认证问题。
这种任务相对集中，Plus通常已经够用。
如果你的日常已经是：
大量Kubernetes环境。
同时维护Helm、CI/CD、私有Registry、多Node、Secret和Runtime配置。
一次故障还需要Codex跨仓库检查镜像版本、部署模板、流水线和集群配置，
这种多文件、多系统、长时间排障越来越频繁，
那Pro会更适合。
判断标准不是：
ImagePullBackOff难不难。
而是：
ChatGPT、Codex是不是已经长期参与完整的容器交付和Kubernetes排障链路。
最后
镜像本地明明能docker pull，为什么Kubernetes还是一直：
ImagePullBackOff？
因为：
本地能拉，只证明“你的电脑”具备拉取条件。
并不能证明：
实际运行Pod的Node也具备同样的账号、网络、DNS、CA和Runtime环境。
所以最快的排查顺序不是：
反复pull。
反复删Pod。
反复改YAML。
而应该是：
Events → Image/Tag → Secret → Auth → Node网络 → CA → Runtime
尤其要记住一点：
ImagePullBackOff只是表象。
真正有价值的是：
Kubelet和Container Runtime第一次拉取镜像时，到底返回了什么错误。
只要先把那条原始错误找出来，大多数ImagePullBackOff问题其实都能很快缩小到一个非常具体的环节。
