2. Kubernetes 核心概念回顾：Pod、Deployment、ReplicaSet、Service 的基本关系与作用

在深入排查 Deployment 镜像拉取超时 故障之前，必须清晰理解 Kubernetes 中四个最核心的抽象对象：Pod、Deployment、ReplicaSet 和 Service。它们之间的层级关系与职责分工，直接决定了故障现象的表现形式与排查路径。

2.1 核心概念定义与职责

2.2 四层对象的关系模型

下图展示了从用户请求到容器运行实例的完整对象层级关系。理解这个层级是定位“镜像拉取超时”故障的第一步——故障信号通常出现在 Pod 状态，但根因可能隐藏在 Deployment 的镜像配置或 Service 的流量策略中。

2.3 各对象在镜像拉取超时场景中的角色

• Pod：故障的直接表现者。当 kubelet 无法在规定时间内从镜像仓库拉取容器镜像时，Pod 状态变为 ImagePullBackOff 或 ErrImagePull。
• ReplicaSet：故障的传播者。ReplicaSet 持续尝试创建新 Pod 以维持期望副本数，导致拉取失败事件反复出现，可能触发 CrashLoopBackOff 连锁反应。
• Deployment：故障的配置源头。镜像地址错误、拉取策略（imagePullPolicy）不当、私有仓库认证缺失等配置，均定义在 Deployment 的 spec.template 中。
• Service：故障的“隐形关联者”。虽然 Service 不直接参与镜像拉取，但若 Service 的 selector 与 Pod 标签不匹配，即使 Pod 最终运行成功，流量也无法到达，造成“拉取成功但服务不可用”的隐蔽故障。

2.4 典型 Deployment 定义示例

以下是一个标准的 Deployment YAML 定义，其中标注了与镜像拉取超时直接相关的关键字段：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25.3          # ← 镜像地址：错误地址/标签导致拉取超时
        imagePullPolicy: Always       # ← 拉取策略：Always 强制每次拉取，增加超时风险
        ports:
        - containerPort: 80
      imagePullSecrets:               # ← 私有仓库认证：缺失导致拉取失败
      - name: regcred

2.5 对象关系速查表

2.6 故障排查中的对象检查顺序

1. 检查 Pod 状态：kubectl get pods 查看 STATUS 列是否为 ImagePullBackOff 或 ErrImagePull。
2. 查看 Pod 事件：kubectl describe pod <pod-name> 定位拉取失败的具体错误信息。
3. 追溯 ReplicaSet：kubectl get replicaset 确认当前活跃的 ReplicaSet 是否与 Deployment 期望版本一致。
4. 审查 Deployment 配置：kubectl describe deployment <deploy-name> 检查 Image、ImagePullPolicy、ImagePullSecrets 字段。
5. 验证 Service 标签匹配：kubectl get endpoints <svc-name> 确认 Endpoints 列表是否包含目标 Pod IP。