Pod 状况

在 Kubernetes 中，许多对象都有状况（condition）。 状况是对象所代表事物的实际状态某些方面的标记。 Pod 有状况，Kubernetes Pod 状况是控制器（以及进行故障排除的人员）了解 Pod 健康状况的重要方面。

Pod 的阶段（phase）提供了 Pod 在其生命周期中所处位置的高级摘要，但单个值无法捕捉全貌。 例如，Pod 可能处于 Running 阶段，但尚未准备好提供流量。 Pod 状况通过独立跟踪 Pod 状态的多个方面来补充阶段， 例如是否已调度、其容器是否就绪、是否正在进行调整大小， 或者 Pod 是否即将由于污点而受到干扰。

Pod 状况的结构

Pod 的状态（status）包括一个 PodConditions 数组，用于指示 Pod 是否已通过某些检查点。

PodCondition 数组的每个元素都有以下字段：

内置 Pod 状况

Kubernetes 管理以下 Pod 状况：

生命周期状况：随着 Pod 经历其生命周期而设置，大致按此顺序： PodScheduled、PodReadyToStartContainers、Initialized、ContainersReady、Ready。

其他状况：响应特定操作或事件而设置： DisruptionTarget、PodResizePending、PodResizeInProgress。

除了上述内置状况外，你还可以使用 Pod 就绪门控定义自定义状况。

生命周期 Pod 状况

随着 Pod 经历其生命周期，kubelet 大致按以下顺序设置以下状况：

1. PodScheduled：Pod 已调度到节点。
2. PodReadyToStartContainers：Pod sandbox 已成功创建并配置了网络。 sandbox 和网络由容器运行时和 CNI 插件设置。
3. Initialized：所有初始容器均已成功完成。 对于没有初始容器的 Pod，此状况在 sandbox 创建之前设置为 True。
4. ContainersReady：Pod 中的所有容器都已就绪。 容器的就绪状态由其就绪探针确定（如果已配置）。
5. Ready：Pod 能够处理请求，应添加到所有匹配的 Service 的负载均衡池中。 未 Ready 的 Pod 会从 Service 端点中移除。

你可以使用 kubectl 检查 Pod 的状况：

kubectl get pod <pod-name> -o yaml

以下显示了运行中的 Pod 的 status.conditions 的样子：

status:
  conditions:
    - type: PodScheduled
      status: "True"
      lastProbeTime: null
      lastTransitionTime: "2026-03-29T08:52:21Z"
      observedGeneration: 1
    - type: PodReadyToStartContainers
      status: "True"
      lastProbeTime: null
      lastTransitionTime: "2026-04-11T06:02:16Z"
      observedGeneration: 1
    - type: Initialized
      status: "True"
      lastProbeTime: null
      lastTransitionTime: "2026-03-29T08:52:21Z"
      observedGeneration: 1
    - type: ContainersReady
      status: "True"
      lastProbeTime: null
      lastTransitionTime: "2026-04-11T06:02:45Z"
      observedGeneration: 1
    - type: Ready
      status: "True"
      lastProbeTime: null
      lastTransitionTime: "2026-04-11T06:02:45Z"
      observedGeneration: 1

PodReadyToStartContainers

Pod 在节点上调度后，需要由 kubelet 准入并挂载任何所需的存储卷。 这些阶段完成后，kubelet 与容器运行时（使用 容器运行时接口（CRI）） 协作，为 Pod 设置运行时 sandbox 并配置网络。 如果启用了 PodReadyToStartContainersCondition 特性门控 （Kubernetes 1.36 中默认启用）， 则 PodReadyToStartContainers 状况将添加到 Pod 的 status.conditions 字段。

当 kubelet 检测到 Pod 没有配置网络的运行时 sandbox 时， PodReadyToStartContainers 状况设置为 False。 这在以下情况下发生：

• 在 Pod 生命周期的早期，kubelet 尚未开始使用容器运行时为 Pod 设置 sandbox。
• 在 Pod 生命周期的后期，Pod sandbox 已被销毁，原因是：
  • 节点重新启动，而 Pod 未被驱逐
  • 对于使用虚拟机进行隔离的容器运行时，Pod sandbox 虚拟机重新启动，这需要创建新的 sandbox 和新的容器网络配置

运行时插件成功完成 Pod 的 sandbox 创建和网络配置后，kubelet 将 PodReadyToStartContainers 状况设置为 True。 在 PodReadyToStartContainers 状况设置为 True 后，kubelet 可以开始拉取容器镜像并创建容器。

对于具有 Init 容器的 Pod，kubelet 在 Init 容器成功完成后 （这发生在运行时插件成功创建 sandbox 和配置网络之后）将 Initialized 状况设置为 True。 对于没有初始容器的 Pod，kubelet 在 sandbox 创建和网络配置开始之前将 Initialized 状况设置为 True。

其他 Pod 状况

以下状况不是正常 Pod 生命周期进程的一部分。 它们响应特定操作或事件而设置。

DisruptionTarget

添加专用的 Pod DisruptionTarget 状况以指示 Pod 即将由于 干扰而被删除。 该状况的 reason 字段还指示 Pod 终止的以下原因之一：

PreemptionByScheduler

Pod 即将被调度器 抢占，以便容纳具有更高优先级的新 Pod。 有关更多信息，请参阅 Pod 优先级抢占。

DeletionByTaintManager

Pod 即将被 Taint Manager（kube-controller-manager 内节点生命周期控制器的一部分）删除， 原因是 Pod 不容忍的 NoExecute 污点； 请参阅基于污点的驱逐。

EvictionByEvictionAPI

Pod 已被标记为使用 Kubernetes API 驱逐。

DeletionByPodGC

绑定到不再存在的节点的 Pod 即将被 Pod 垃圾回收删除。

TerminationByKubelet

Pod 已被 kubelet 终止，原因是节点压力驱逐、 节点体面关闭或 为系统关键 Pod 进行抢占。

在所有其他干扰场景中，例如由于超过 Pod 容器限制而导致的驱逐， Pod 不会收到 DisruptionTarget 状况，因为干扰可能是由 Pod 引起的，并且会在重试时再次发生。

除了清理 Pod 外，Pod 垃圾回收器（PodGC）还会将它们标记为失败（如果它们处于非终止阶段） （另请参阅 Pod 垃圾回收）。

使用 Job（或 CronJob）时，你可能希望将这些 Pod 干扰状况用作 Job 的 Pod 失败策略的一部分。

有关更多详细信息，请参阅干扰。

PodResizePending 和 PodResizeInProgress

kubelet 更新 Pod 的状态状况以指示调整大小请求的状态：

• type: PodResizePending：kubelet 无法立即批准请求。 message 字段提供原因说明。
  • reason: Infeasible：请求的调整大小在当前节点上不可能（例如，请求的资源超过节点拥有的资源）。
  • reason: Deferred：请求的调整大小目前不可能，但以后可能变得可行（例如，如果另一个 Pod 被移除）。 kubelet 将重试调整大小。
• type: PodResizeInProgress：kubelet 已接受调整大小并分配了资源，但更改仍在应用中。 这通常很短暂，但可能根据资源类型和运行时行为花费更长时间。 执行期间的任何错误都在 message 字段中报告（以及 reason: Error）。

如果请求的调整大小被 Deferred，kubelet 将定期重试调整大小，例如当另一个 Pod 被移除或缩容时。

有关 Pod 调整大小的更多详细信息， 请参阅调整分配给容器的 CPU 和内存资源。

增强 Pod 就绪

你的应用可以将额外的反馈或信号注入 Pod 的 .status； 这称为增强 Pod 就绪。 要使用此功能，请在 Pod 的 spec 中设置 readinessGates， 以指定 kubelet 评估 Pod 就绪的其他状况列表。 然后你实现或安装一个管理这些自定义状况的控制器， kubelet 使用该控制器作为额外输入来决定 Pod 是否就绪。

就绪门由 Pod 的 status.condition 字段的当前状态确定。 如果 Kubernetes 在 Pod 的 status.conditions 字段中找不到这样的状况， 则该状况的状态默认为 "False"。

kind: Pod
...
spec:
  readinessGates:
    - conditionType: "www.example.com/feature-1"
status:
  conditions:
    - type: Ready                              # 内置的 PodCondition
      status: "False"
      lastProbeTime: null
      lastTransitionTime: 2018-01-01T00:00:00Z
    - type: "www.example.com/feature-1"        # 额外的 PodCondition
      status: "False"
      lastProbeTime: null
      lastTransitionTime: 2018-01-01T00:00:00Z
  containerStatuses:
    - containerID: docker://abcd...
      ready: true
...

你添加的 Pod 状况必须具有符合 Kubernetes 标签键格式的名称。

Pod 就绪的状态

要为 Pod 设置这些 status.conditions，应用和 operators 应使用 Pod 状态子资源的 PATCH 操作。 你可以使用 kubectl patch 和 --subresource=status， 或使用 Kubernetes 客户端库编写代码来设置自定义 Pod 状况以实现 Pod 就绪。

对于使用自定义状况的 Pod，仅当以下两个陈述都适用时，该 Pod 才被评估为就绪：

• Pod 中的所有容器都已就绪。
• readinessGates 中指定的所有状况都为 True。

当 Pod 的容器为 Ready 但至少缺少一个自定义状况或为 False 时， kubelet 将 Pod 的 Ready 状况设置为 status: "False" 及 reason: ReadinessGatesNotReady。

接下来

• 了解 Pod 生命周期。
• 了解干扰。
• 了解容器探针以及它们如何影响 Pod 就绪。
• 了解如何就地调整 Pod 资源。