Pod 状态 (Pod Conditions)

在 Kubernetes 中，许多对象都有条件（Conditions）。条件是对象所代表事物的实际状态某些方面的标志。Pod 具有条件，而 Kubernetes Pod 条件是控制器（以及进行故障排查的人员）理解 Pod 健康状况的一个重要方面。

Pod 的 阶段（Phase） 提供了 Pod 在其生命周期中所处位置的高级概述，但单一的值无法捕捉全貌。例如，Pod 可能处于 Running 阶段但尚未准备好处理流量。Pod 条件通过独立跟踪 Pod 状态的多个方面来补充阶段，例如 Pod 是否已被调度、容器是否就绪、调整大小（Resize）是否正在进行，或者 Pod 是否因为 污点（Taint） 而即将被中断。

Pod 条件的结构

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

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

内置 Pod 条件

Kubernetes 管理以下 Pod 条件

生命周期条件：随着 Pod 生命周期进展而设置，大致顺序为：PodScheduled、PodReadyToStartContainers、Initialized、ContainersReady、Ready。

其他条件：针对特定操作或事件设置：DisruptionTarget、PodResizePending、PodResizeInProgress。

除了上述内置条件外，您还可以使用 Pod 就绪性门控（Readiness Gates） 定义自定义条件。

生命周期 Pod 条件

随着 Pod 的生命周期进展，kubelet 大致按照以下顺序设置这些条件

1. PodScheduled：Pod 已被调度到某个节点。
2. PodReadyToStartContainers：Pod 沙箱已成功创建，网络已配置完成。沙箱和网络由 容器运行时 和 CNI 插件设置。
3. Initialized：所有 初始化容器（Init Containers） 已成功完成。对于没有初始化容器的 Pod，该项在沙箱创建前被设置为 True。
4. ContainersReady：Pod 中的所有容器都已就绪。容器的就绪性由其 就绪探针（readiness probe） 决定（如果已配置）。
5. Ready：Pod 能够处理请求，并且应该被添加到所有匹配的 服务（Services） 的负载均衡池中。不处于 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 配置网络。如果启用了 PodReadyToStartContainersCondition 特性门控（Kubernetes 1.36 默认启用），PodReadyToStartContainers 条件将被添加到 Pod 的 status.conditions 字段中。

当 kubelet 检测到 Pod 没有配置好网络的运行时沙箱时，会将 PodReadyToStartContainers 条件设置为 False。这种情况发生在以下场景中

• 在 Pod 生命周期的早期，当 kubelet 尚未开始使用容器运行时为 Pod 设置沙箱时。
• 在 Pod 生命周期的后期，当 Pod 沙箱由于以下原因被销毁时
  • 节点重启，且 Pod 未被驱逐
  • 对于使用虚拟机进行隔离的容器运行时，Pod 沙箱虚拟机重启，这随后需要创建新的沙箱并进行全新的容器网络配置。

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

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

其他 Pod 条件

以下条件不属于正常的 Pod 生命周期进展的一部分。它们是针对特定操作或事件设置的。

DisruptionTarget

添加了一个专门的 Pod DisruptionTarget 条件，以指示 Pod 即将因为 中断（Disruption） 而被删除。该条件的 reason 字段额外指示了 Pod 终止的以下原因之一

PreemptionByScheduler

Pod 即将被调度器 抢占（preempted），以便为具有更高优先级的新 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 标记为失败（另请参阅 Pod 垃圾回收）。

当使用 Job（或 CronJob）时，您可能希望将这些 Pod 中断条件用作 Job 的 Pod 失败策略 的一部分。

有关更多详细信息，请参阅 中断（Disruptions）。

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                              # a built-in PodCondition
      status: "False"
      lastProbeTime: null
      lastTransitionTime: 2018-01-01T00:00:00Z
    - type: "www.example.com/feature-1"        # an extra PodCondition
      status: "False"
      lastProbeTime: null
      lastTransitionTime: 2018-01-01T00:00:00Z
  containerStatuses:
    - containerID: docker://abcd...
      ready: true
...

您添加的 Pod 条件名称必须符合 Kubernetes 标签键格式。

Pod 就绪性状态

为了设置 Pod 的这些 status.conditions，应用程序和 Operator 应在 Pod 的状态子资源上使用 PATCH 操作。您可以使用带有 --subresource=status 参数的 kubectl patch，或者使用 Kubernetes 客户端库 编写代码来设置自定义 Pod 就绪性条件。

对于使用自定义条件的 Pod，该 Pod 只有在以下两个陈述都成立时才被评估为就绪

• Pod 中的所有容器都已就绪。
• readinessGates 中指定的所有条件均为 True。

当 Pod 的容器已就绪，但至少有一个自定义条件缺失或为 False 时，kubelet 会将 Pod 的 Ready 条件设置为 status: "False"，并附带 reason: ReadinessGatesNotReady。

接下来

• 了解 Pod 生命周期。
• 了解 中断（Disruptions）。
• 了解 容器探针 及其如何影响 Pod 就绪性。
• 了解如何 就地调整 Pod 资源。