Kubernetes Pod出现ImagePullBackOff时，开发者常在节点终端curl Registry并宣布网络正常。真正发起Manifest和Blob请求的通常是containerd服务，它由systemd或节点系统启动，使用自己的环境、CA、Registry配置和凭据。
镜像拉取调用链
| 组件 | 职责 | 排查重点 |
|---|---|---|
| kubelet | 根据Pod规范请求镜像 | Pod事件、ImagePullSecrets和镜像名 |
| CRI插件 | 连接kubelet与运行时 | Runtime配置与命名空间 |
| containerd | 访问Registry并管理内容 | 服务代理、认证、CA与Blob |
| Registry/Token服务 | 认证、Manifest和镜像层 | 401、403、429、重定向和证书 |
代理为什么要配置在服务环境
containerd是长期运行的系统服务，管理员Shell中的HTTP_PROXY不会自动进入进程。应使用systemd drop-in或平台支持方式配置，执行daemon-reload并重启服务。操作前确认节点维护和工作负载影响。
ctr、crictl和Pod测试有什么区别
ctr是containerd低层客户端，命名空间和参数可能与Kubernetes不同；crictl更接近CRI路径；最终仍需通过测试Pod和事件验证ImagePullSecrets、镜像策略和调度节点。单个工具成功不能覆盖全部链路。
NO_PROXY应包含哪些Registry
内部Registry、Token服务或对象存储可能应直连。应根据实际主机与端口精确配置，并确认Blob是否重定向到另一个域名。不要把所有域名后缀都加入绕过，也不要忘记集群内部和链路本地地址。
Registry配置与HTTP代理有何区别
containerd可通过受支持的hosts与证书配置定义Registry端点、Mirror和CA；HTTP代理则决定网络出口。Mirror改变镜像内容来源和供应链责任，不能只作为“网络加速”随意添加未知地址。
登录成功为何Blob仍失败
Token请求很小，真实拉取会访问Manifest和多个大Blob，还可能重定向至对象存储。代理连接上限、带宽、读取超时和429限流通常在大层下载时才暴露。
常见错误如何判断
- 407：containerd到正向代理认证；
- 401/403：Registry、Token或仓库权限；
- 429：Registry限流；
- manifest unknown：镜像标签、Digest或平台；
- x509：节点CA、域名或Registry证书；
- 超时：DNS、代理、Blob端点和容量。
ImagePullSecrets在哪一层使用
Kubernetes把匹配的Secret提供给CRI拉取流程。Secret命名空间、ServiceAccount和Registry主机匹配错误，会导致匿名拉取或认证失败。代理凭据不应混入ImagePullSecret；两套凭据分别管理。
多节点为何只有部分Pod失败
节点可能拥有不同containerd版本、服务环境、CA或DNS。Pod调度到异常节点后才失败，看起来像随机问题。应将事件与节点关联，比较运行时配置和镜像缓存；缓存命中也可能掩盖某些节点无法联网。
证书轮换怎么避免间歇失败
为所有相关节点分发新CA，验证后滚动重启containerd，并保持新旧证书的合理过渡。不要只更新控制平面或一台节点。跳过TLS验证会扩大镜像供应链风险。
排查顺序
- 记录containerd、kubelet和CRI版本；
- 从Pod事件确认镜像、节点和错误阶段；
- 检查containerd服务代理与NO_PROXY；
- 区分407、Registry权限、429与TLS；
- 使用crictl和测试Pod验证实际链路；
- 比较所有节点的CA和配置；
- 检查Digest、平台与镜像完整性。
Registry认证、Manifest和Blob下载的分层过程，可继续参考Docker Registry镜像代理排查。
结论
containerd拉取失败应从节点服务进程和CRI链路排查。终端测试、ctr和缓存命中都可能误导；只有在实际调度节点通过Kubernetes拉取成功，才能说明配置完整。
