Kubernetes 私有镜像报 ImagePullBackOff：Secret 必须和实际 Pod 在同一命名空间

私有仓库中已有镜像，其他工作负载也能拉取，但新 Deployment 的 Pod 仍停在 ImagePullBackOff。如果凭据 Secret 在 team-app，报错 Pod 却在 default，应先核对实际部署对象和命名空间。另一处能用的凭据，不会自动被当前 Pod 引用。

ImagePullBackOff 只表示拉取失败后正在退避重试。镜像名不存在、认证失败、网络或证书错误都可能进入这个状态；只有事件指向找不到拉取凭据，并且命名空间不一致时，才沿下面的路径处理。

查看报错的究竟是哪一个 Pod

以下名称和路径均为示例。先确认当前集群，再明确指定命名空间查看对象：

kubectl config current-context
kubectl get pods -A
kubectl get deployment example-app -n team-app -o yaml
kubectl describe pod example-app-abc123 -n team-app

-A 帮助识别同名应用是否同时存在于 default 和目标命名空间。后两条要替换为实际对象；查看目标 Deployment 的模板与 Pod 的 metadata.namespace、镜像和 imagePullSecrets，不要只检查本地 YAML。

已经在目标命名空间运行的新版 Pod，与另一命名空间里遗留的失败 Pod，是两个对象。查看旧对象不会反映新部署的拉取结果。也不要未经确认就删除全部同名工作负载，其他命名空间可能属于不同环境。

describe 的事件若出现 FailedToRetrieveImagePullSecret，继续检查引用名称；若是仓库拒绝、镜像不存在或连接超时，应分别查凭据权限、镜像引用与网络，不能只改 namespace。

拉取凭据不会跨 namespace 查找

Pod 的 imagePullSecrets 引用同一命名空间里的 Secret。可用以下只读命令查看名称与类型，不必输出 Secret 内容：

kubectl get secret regcred -n team-app

拉取凭据应采用支持的 kubernetes.io/dockerconfigjson 或 kubernetes.io/dockercfg 类型，仓库地址、账户权限与镜像所在仓库也要相符。Secret 存在不等于凭据有效。

如果只有 default 中存在 regcred，不能在字段中写成 default/regcred 来跨空间引用。需要通过获准的凭据管理流程，在实际工作负载的命名空间配置合适的拉取凭据，并按最小范围授权。避免把密码放进聊天、共享日志或命令历史。

Deployment 的相关结构可以明确为以下形式；这是局部示例，容器配置和其他字段按应用保留：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-app
  namespace: team-app
spec:
  template:
    spec:
      imagePullSecrets:
        - name: regcred

team-app 必须已存在，Secret 也应在该空间。清单中的 namespace 与执行命令所选目标保持一致；明确检查实际结果，避免把对象部署到预期之外的位置。

搬命名空间不是原地修改

如果工作负载部署错了位置，调整 namespace 会在另一空间管理新的对象，不是把现有 Pod 原地搬过去。配置、Service、权限及存储引用都需要核对，不能只修改一个字段就认定迁移完整。

先保存现有清单与相关配置，在维护安排允许的情况下部署目标对象，确认应用就绪、依赖和访问路径正确，再决定如何处理旧对象。回退时恢复原工作负载与流量配置；旧空间已承担业务时，应保留它直到迁移验收完成。

修复后查看正确空间中的新 Pod 与事件：拉取成功，容器按预期启动并通过应用自己的就绪条件。旧的退避事件可能仍留在历史中，验收应以当前对象和新事件为准。若拉取凭据已经找到却仍认证失败，继续核对仓库授权，不要扩大 Kubernetes 权限来替代仓库凭据。