国内团队容器镜像落地一页清单：开发机、构建机与集群出口

如果你的团队经常遇到「我本地能跑、CI 不能跑、集群又不能跑」，大概率不是业务代码问题，而是镜像拉取路径不一致。本文用 checklist 形式收敛常见问题。

1. 出口一致性（最容易被低估）

• 研发机的 Docker / Podman 是否与 CI 使用相同的 Registry 可达路径？
• 集群节点是否能访问构建机推送的 Registry？
• 代理、镜像缓存与直连策略是否写成文档，而不是口口相传？

2. 凭据与权限（最常见隐性故障）

• 私有仓库凭据是否集中管理并定期轮换？
• CI 与 K8s 的 pull secret 是否遵循最小权限？
• robot account / token 的归属清晰（谁创建、谁回收）？

3. 版本策略（从第一天就该讨论）

• 生产环境是否禁止裸奔 latest（除非有明确例外条款）？
• 是否定义「基础镜像升级」的责任人与频率？
• 关键服务是否有回滚用的上一个镜像版本（tag 或 digest）？

4. 缓存与加速（理解边界）

• 团队是否清楚「缓存 ≠ 永远最新」？
• 安全补丁窗口是否与镜像刷新策略联动？

5. 可观测性（出问题不要只靠猜）

• ImagePull 失败是否能快速定位到「引用错误 / 权限 / 网络」之一？
• 是否有统一的镜像清单（至少包含镜像名、用途、负责人）？

6. 小结

镜像问题多数是流程问题。把这份清单当作团队月度复盘的一页纸：勾选越少，技术债越可能在镜像层爆发。