Pod 生命周期

本页介绍了 Pod 的生命周期。Pod 遵循一个明确定义的生命周期，始于 Pending 阶段，如果其至少一个主容器成功启动则进入 Running 阶段，然后根据 Pod 中是否有容器终止失败，进入 Succeeded 或 Failed 阶段。

与单个应用程序容器类似，Pod 被认为是相对短暂（而非持久）的实体。Pod 被创建、分配一个唯一的 ID (UID)，并被调度到节点上运行，它们将一直保留在那里直到终止（根据重启策略）或删除。如果一个节点死亡，在该节点上运行（或计划在该节点上运行）的 Pod 将被标记为删除。控制平面会在超时周期后将 Pod 标记为移除。

Pod 生命周期

当 Pod 运行时，kubelet 能够重启容器以处理某些类型的故障。在一个 Pod 中，Kubernetes 跟踪不同的容器状态，并决定采取什么措施使 Pod 再次健康。

在 Kubernetes API 中，Pod 既有规范（specification）也有实际状态（status）。Pod 对象的状态包含一组Pod 条件。如果对你的应用程序有用，你还可以将自定义就绪信息注入到 Pod 的条件数据中。

Pod 在其生命周期内只会被调度一次；将 Pod 分配给特定节点称为 binding（绑定），选择使用哪个节点的过程称为 scheduling（调度）。一旦 Pod 被调度并绑定到节点，Kubernetes 就会尝试在该节点上运行该 Pod。Pod 在该节点上运行，直到它停止，或者直到 Pod 被终止；如果 Kubernetes 无法在选定的节点上启动 Pod（例如，如果在 Pod 启动之前节点崩溃），那么那个特定的 Pod 永远不会启动。

你可以使用Pod 调度就绪来延迟 Pod 的调度，直到其所有 scheduling gates（调度门）被移除。例如，你可能想定义一组 Pod，但只在所有 Pod 都创建完成后才触发调度。

Pod 与故障恢复

如果 Pod 中的一个容器失败，Kubernetes 可能会尝试重启该特定容器。阅读Pod 如何处理容器故障以了解更多信息。

然而，Pod 可能会以集群无法恢复的方式失败，在这种情况下，Kubernetes 不会尝试进一步修复 Pod；相反，Kubernetes 会删除 Pod，并依赖其他组件提供自动修复。

如果一个 Pod 被调度到节点上，而该节点随后失败，该 Pod 会被视为不健康，Kubernetes 最终会删除该 Pod。Pod 无法在因资源不足或节点维护导致的驱逐中幸存。

Kubernetes 使用一个称为控制器的更高级别抽象，负责管理相对可抛弃的 Pod 实例。

一个特定的 Pod（由 UID 定义）永远不会被“重新调度”到不同的节点；相反，该 Pod 可以被一个新的、几乎相同的 Pod 替换。如果你创建一个替代 Pod，它甚至可以拥有与旧 Pod 相同的名称（如 .metadata.name），但该替代 Pod 将拥有与旧 Pod 不同的 .metadata.uid。

Kubernetes 不保证现有 Pod 的替代 Pod 会被调度到与被替换的旧 Pod 相同的节点上。

关联的生命周期

当某个事物被说成与 Pod 具有相同的生命周期时，例如一个数据卷，这意味着该事物会一直存在，只要那个特定的 Pod（具有完全相同的 UID）存在。如果该 Pod 因任何原因被删除，即使创建了一个完全相同的替代 Pod，相关的事物（在这个例子中是数据卷）也会被销毁并重新创建。

Pod 阶段

Pod 的 status 字段是一个 PodStatus 对象，该对象包含一个 phase 字段。

Pod 的阶段是 Pod 在其生命周期中所处位置的简单、高层级总结。阶段并非旨在对容器或 Pod 状态进行全面汇总，也并非旨在成为一个全面的状态机。

Pod 阶段值的数量和含义受到严格限制。除此处文档所述外，不应假定具有特定 phase 值的 Pod 的任何其他信息。

以下是 phase 的可能取值

  NAMESPACE               NAME               READY   STATUS             RESTARTS   AGE
  alessandras-namespace   alessandras-pod    0/1     CrashLoopBackOff   200        2d9h

自 Kubernetes 1.27 版本起，kubelet 会将已删除的 Pod（静态 Pod 和没有 Finalizer 的强制删除的 Pod 除外）在从 API server 删除之前，转换为最终阶段（根据 Pod 容器的退出状态，可能是 Failed 或 Succeeded）。

如果节点死亡或与集群的其余部分断开连接，Kubernetes 会应用策略将丢失节点上所有 Pod 的 phase 设置为 Failed。

容器状态

除了 Pod 的总体阶段外，Kubernetes 还跟踪 Pod 内部每个容器的状态。你可以使用容器生命周期钩子来在容器生命周期中的特定点触发事件运行。

一旦调度器将 Pod 分配给 Node，kubelet 就会使用容器运行时为该 Pod 开始创建容器。容器有三种可能的状态：Waiting（等待）、Running（运行中）和 Terminated（已终止）。

要检查 Pod 中容器的状态，可以使用 kubectl describe pod <pod 名称>。输出会显示该 Pod 中每个容器的状态。

每种状态都有特定的含义

Waiting

如果容器既不在 Running 状态也不在 Terminated 状态，则它处于 Waiting 状态。处于 Waiting 状态的容器仍在运行完成启动所需的各项操作：例如，从容器镜像仓库拉取容器镜像，或应用Secret 数据。当你使用 kubectl 查询包含处于 Waiting 状态容器的 Pod 时，还会看到一个 Reason 字段，该字段总结了容器处于该状态的原因。

Running

Running 状态表示容器正在执行，没有问题。如果配置了 postStart 钩子，它已经执行并完成。当你使用 kubectl 查询包含处于 Running 状态容器的 Pod 时，还会看到关于容器何时进入 Running 状态的信息。

Terminated

处于 Terminated 状态的容器已经开始执行，然后要么运行完成，要么因某种原因失败。当你使用 kubectl 查询包含处于 Terminated 状态容器的 Pod 时，会看到原因、退出代码以及该容器执行时段的开始时间和结束时间。

如果容器配置了 preStop 钩子，该钩子会在容器进入 Terminated 状态之前运行。

Pod 如何处理容器故障

Kubernetes 使用 Pod spec 中定义的restartPolicy 来管理 Pod 内部的容器故障。此策略决定了 Kubernetes 如何响应因错误或其他原因而退出的容器，其处理顺序如下：

1. 初始崩溃：Kubernetes 会根据 Pod 的 restartPolicy 立即尝试重启。
2. 重复崩溃：初始崩溃后，Kubernetes 会对后续重启应用指数回退延迟，如restartPolicy 中所述。这可以防止快速、重复的重启尝试导致系统过载。
3. CrashLoopBackOff 状态：这表明对于处于崩溃循环、反复失败和重启的给定容器，回退延迟机制当前正在生效。
4. 回退重置：如果容器成功运行了一定时间（例如 10 分钟），Kubernetes 会重置回退延迟，将任何新的崩溃视为第一次崩溃。

实际上，CrashLoopBackOff 是一种可能在描述或列出 Pod 时从 kubectl 命令输出中看到的条件或事件，当 Pod 中的容器无法正常启动然后在一个循环中不断尝试并失败时发生。

换句话说，当容器进入崩溃循环时，Kubernetes 会应用容器重启策略中提到的指数回退延迟。此机制可防止有故障的容器通过持续失败的启动尝试使系统过载。

CrashLoopBackOff 可能由以下问题引起：

• 导致容器退出的应用程序错误。
• 配置错误，例如错误的环境变量或缺失的配置文件。
• 资源限制，容器可能没有足够的内存或 CPU 来正常启动。
• 如果应用程序未在预期时间内开始提供服务，则健康检查会失败。
• 容器的存活探针或启动探针返回 Failure 结果，如探针部分所述。

要调查 CrashLoopBackOff 问题的根本原因，用户可以：

1. 检查日志：使用 kubectl logs <pod 名称> 查看容器的日志。这通常是诊断导致崩溃的问题的最直接方法。
2. 检查事件：使用 kubectl describe pod <pod 名称> 查看 Pod 的事件，这可以提供关于配置或资源问题的线索。
3. 检查配置：确保 Pod 配置（包括环境变量和挂载的数据卷）正确无误，并且所有必需的外部资源都可用。
4. 检查资源限制：确保容器分配了足够的 CPU 和内存。有时，增加 Pod 定义中的资源可以解决此问题。
5. 调试应用程序：应用程序代码中可能存在 Bug 或配置错误。在本地或开发环境中运行此容器镜像可以帮助诊断应用程序特有的问题。

容器重启策略

Pod 的 spec 中有一个 restartPolicy 字段，可能的值为 Always、OnFailure 和 Never。默认值为 Always。

Pod 的 restartPolicy 适用于 Pod 中的应用程序容器和常规的init 容器。边车容器会忽略 Pod 级别的 restartPolicy 字段：在 Kubernetes 中，边车容器被定义为 initContainers 中的一个条目，其容器级别的 restartPolicy 设置为 Always。对于因错误退出的 init 容器，如果 Pod 级别的 restartPolicy 是 OnFailure 或 Always，kubelet 会重启该 init 容器。

• Always：在容器终止后自动重启。
• OnFailure：仅在容器以错误状态（非零退出状态码）退出时重启。
• Never：不自动重启已终止的容器。

当 kubelet 根据配置的重启策略处理容器重启时，这仅适用于在同一 Pod 内部并运行在同一节点上的替换容器。Pod 中的容器退出后，kubelet 会以指数回退延迟（10 秒、20 秒、40 秒等）的方式重启它们，此延迟上限为 300 秒（5 分钟）。一旦容器无故障运行 10 分钟，kubelet 会重置该容器的重启回退计时器。边车容器和 Pod 生命周期解释了在 init 容器上指定 restartpolicy 字段时的行为。

缩短容器重启延迟

启用 Alpha 特性门控 ReduceDefaultCrashLoopBackOffDecay 后，集群范围内的容器启动重试将从 1 秒开始（而不是 10 秒），并且每次重启时以 2 倍指数增加，直到最大延迟达到 60 秒（而不是 300 秒，即 5 分钟）。

如果你将此特性与 Alpha 特性 KubeletCrashLoopBackOffMax（如下所述）一起使用，则各个节点可能具有不同的最大延迟。

可配置的容器重启延迟

启用 Alpha 特性门控 KubeletCrashLoopBackOffMax 后，你可以将容器启动重试之间的最大延迟从默认的 300 秒（5 分钟）重新配置。此配置通过 kubelet 配置在每个节点上设置。在你的kubelet 配置中，在 crashLoopBackOff 下将 maxContainerRestartPeriod 字段设置为介于 "1s" 和 "300s" 之间。如上文容器重启策略中所述，该节点上的延迟仍将从 10 秒开始，并且每次重启时以 2 倍指数增加，但现在将限制在你配置的最大值。如果你配置的 maxContainerRestartPeriod 小于默认初始值 10 秒，则初始延迟将改为设置为配置的最大值。

参阅以下 kubelet 配置示例

# container restart delays will start at 10s, increasing
# 2x each time they are restarted, to a maximum of 100s
kind: KubeletConfiguration
crashLoopBackOff:
    maxContainerRestartPeriod: "100s"

# delays between container restarts will always be 2s
kind: KubeletConfiguration
crashLoopBackOff:
    maxContainerRestartPeriod: "2s"

如果你将此特性与 Alpha 特性 ReduceDefaultCrashLoopBackOffDecay（如上所述）一起使用，则集群中初始回退和最大回退的默认值将不再是 10 秒和 300 秒，而是 1 秒和 60 秒。节点级配置优先于 ReduceDefaultCrashLoopBackOffDecay 设置的默认值，即使这会导致某个节点的最大回退时间比集群中其他节点更长。

Pod 条件

Pod 具有 PodStatus，其中包含一个PodCondition 数组，指示 Pod 已经或尚未通过的条件。Kubelet 管理以下 PodConditions：

• PodScheduled：Pod 已调度到节点。
• PodReadyToStartContainers：（Beta 特性；默认启用）Pod sandbox 已成功创建且网络已配置。
• ContainersReady：Pod 中的所有容器都已就绪。
• Initialized：所有init 容器均已成功完成。
• Ready：Pod 能够处理请求，并且应被添加到所有匹配 Service 的负载均衡池中。

Pod 就绪性

你的应用程序可以将额外的反馈或信号注入 PodStatus：Pod 就绪性。要使用此功能，请在 Pod 的 spec 中设置 readinessGates 来指定 kubelet 用于评估 Pod 就绪性的附加条件列表。

就绪性门由 Pod 的 status.condition 字段的当前状态决定。如果在 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 就绪性的状态

kubectl patch 命令不支持修补对象状态。要设置 Pod 的这些 status.conditions，应用程序和Operator 应使用 PATCH 操作。你可以使用Kubernetes 客户端库来编写代码，设置 Pod 就绪性的自定义 Pod 条件。

对于使用自定义条件的 Pod，该 Pod 仅在满足以下两个条件时才被评估为就绪：

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

当 Pod 的容器就绪但至少一个自定义条件缺失或为 False 时，kubelet 将 Pod 的条件设置为 ContainersReady。

Pod 网络就绪性

在一个 Pod 被调度到节点上之后，它需要被 kubelet 接纳，并且需要挂载所有必需的存储卷。一旦这些阶段完成，kubelet 会与容器运行时协作（使用 容器运行时接口 (CRI)），来为 Pod 设置运行时沙箱并配置网络。如果 PodReadyToStartContainersCondition 功能门 被启用（Kubernetes 1.33 默认启用），PodReadyToStartContainers 条件将被添加到 Pod 的 status.conditions 字段中。

当 Kubelet 检测到 Pod 没有配置网络的运行时沙箱时，PodReadyToStartContainers 条件被设置为 False。这发生在以下场景：

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

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

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

容器探针

探针（probe）是 kubelet 对容器周期性执行的诊断。为了执行诊断，kubelet 要么在容器内执行代码，要么发起网络请求。

检查机制

有四种不同的方式可以使用探针检查容器。每个探针必须精确定义这四种机制中的一种：

exec

在容器内执行指定命令。如果命令以状态码 0 退出，诊断就被认为是成功的。

grpc

使用 gRPC 执行远程过程调用。目标应该实现 gRPC 健康检查。如果响应的 status 为 SERVING，诊断就被认为是成功的。

httpGet

对 Pod 的 IP 地址上的指定端口和路径执行 HTTP GET 请求。如果响应的状态码大于或等于 200 且小于 400，诊断就被认为是成功的。

tcpSocket

对 Pod 的 IP 地址上的指定端口执行 TCP 检查。如果端口打开，诊断就被认为是成功的。如果远程系统（容器）在连接打开后立即关闭连接，这也算作健康。

探针结果

每个探针有三种结果：

成功

容器通过了诊断。

失败

容器未能通过诊断。

Unknown

诊断失败（不应采取任何行动，kubelet 将进行进一步检查）。

探针类型

kubelet 可以选择对运行中的容器执行三种类型的探针并作出反应：

存活探针

指示容器是否正在运行。如果存活探针失败，kubelet 会终止容器，然后容器将受到其重启策略的影响。如果容器未提供存活探针，默认状态是 Success。

就绪探针

指示容器是否已准备好响应请求。如果就绪探针失败，EndpointSlice 控制器会从与该 Pod 匹配的所有 Service 的 EndpointSlices 中移除该 Pod 的 IP 地址。在初始延迟之前的默认就绪状态是 Failure。如果容器未提供就绪探针，默认状态是 Success。

启动探针

指示容器内的应用是否已启动。如果提供了启动探针，则在启动探针成功之前，所有其他探针都将被禁用。如果启动探针失败，kubelet 会终止容器，然后容器将受到其重启策略的影响。如果容器未提供启动探针，默认状态是 Success。

有关如何设置存活探针、就绪探针或启动探针的更多信息，请参阅配置存活、就绪和启动探针。

何时使用存活探针？

如果容器中的进程在遇到问题或变得不健康时能够自行崩溃，则不一定需要存活探针；kubelet 将根据 Pod 的 restartPolicy 自动执行正确的操作。

如果你希望容器在探针失败时被终止并重启，则指定一个存活探针，并指定 restartPolicy 为 Always 或 OnFailure。

何时使用就绪探针？

如果你希望仅在探针成功后才开始向 Pod 发送流量，则指定一个就绪探针。在这种情况下，就绪探针可能与存活探针相同，但 spec 中存在就绪探针意味着 Pod 将在不接收任何流量的情况下启动，并且仅在探针开始成功后才开始接收流量。

如果你希望容器能够自行停机维护，可以指定一个就绪探针，该探针检查一个专门用于就绪的端点，该端点与存活探针不同。

如果你的应用对后端服务有严格依赖，则可以同时实现存活探针和就绪探针。存活探针在应用本身健康时通过，但就绪探针还会额外检查每个所需的后端服务是否可用。这有助于你避免将流量导向那些只能返回错误消息的 Pod。

如果你的容器需要在启动期间加载大量数据、配置文件或进行迁移，你可以使用启动探针。但是，如果你想区分已经失败的应用和仍在处理启动数据的应用，你可能更倾向于使用就绪探针。

何时使用启动探针？

启动探针对于容器启动需要很长时间的 Pod 很有用。你可以不设置较长的存活探测间隔，而是为容器启动时配置一个单独的探测设置，允许比存活探测间隔更长的时间。

如果你的容器通常启动时间超过 \( initialDelaySeconds + failureThreshold \times periodSeconds \)，则应指定一个启动探针，该探针检查与存活探针相同的端点。periodSeconds 的默认值为 10 秒。然后应将其 failureThreshold 设置得足够高，以允许容器启动，同时不要更改存活探针的默认值。这有助于防止死锁。

Pod 的终止

由于 Pod 代表在集群节点上运行的进程，因此重要的是允许这些进程在不再需要时优雅地终止（而不是被 KILL 信号突然停止而没有清理机会）。

设计目标是让你能够请求删除并知道进程何时终止，同时也能确保删除最终完成。当你请求删除 Pod 时，集群会记录并跟踪在允许强制终止 Pod 之前的预期优雅终止期。有了这种强制关机跟踪，kubelet 会尝试优雅关机。

通常，对于 Pod 的这种优雅终止，kubelet 会向容器运行时发出请求，尝试通过首先向每个容器中的主进程发送一个带有优雅终止期超时的 TERM (又称 SIGTERM) 信号来停止 Pod 中的容器。容器运行时异步处理停止容器的请求。不能保证这些请求的处理顺序。许多容器运行时尊重容器镜像中定义的 STOPSIGNAL 值，如果不同，则发送容器镜像配置的 STOPSIGNAL 而不是 TERM。优雅终止期到期后，KILL 信号会被发送到所有剩余的进程，然后 Pod 从 API 服务器中删除。如果在等待进程终止期间 kubelet 或容器运行时的管理服务重启，集群会从头开始重试，包括完整的原始优雅终止期。

停止信号

用于终止容器的停止信号可以在容器镜像中通过 STOPSIGNAL 指令定义。如果在镜像中没有定义停止信号，则使用容器运行时的默认信号（containerd 和 CRI-O 的默认信号都是 SIGTERM）来终止容器。

定义自定义停止信号

如果 ContainerStopSignals 功能门已启用，你可以在容器生命周期中为容器配置自定义停止信号。我们需要 Pod 的 spec.os.name 字段存在，作为在容器生命周期中定义停止信号的必要条件。有效信号列表取决于 Pod 调度到的操作系统。对于调度到 Windows 节点的 Pod，我们只支持 SIGTERM 和 SIGKILL 作为有效信号。

以下是一个定义了自定义停止信号的 Pod 规约示例：

spec:
  os:
    name: linux
  containers:
    - name: my-container
      image: container-image:latest
      lifecycle:
        stopSignal: SIGUSR1

如果在生命周期中定义了停止信号，这将覆盖容器镜像中定义的信号。如果在容器 spec 中没有定义停止信号，则容器将回退到默认行为。

Pod 终止流程

Pod 终止流程图解，示例如下：

1. 你使用 kubectl 工具手动删除一个特定的 Pod，使用默认的优雅终止期（30 秒）。

2. API 服务器中的 Pod 将更新为该 Pod 被视为“死亡”的时间以及优雅终止期。如果你使用 kubectl describe 检查你正在删除的 Pod，该 Pod 将显示为“Terminating”。在运行该 Pod 的节点上：一旦 kubelet 看到 Pod 被标记为终止（已设置优雅关机时长），kubelet 就会开始本地 Pod 关机过程。

   1. 如果 Pod 的某个容器定义了 preStop 钩子，并且 Pod spec 中的 terminationGracePeriodSeconds 未设置为 0，则 kubelet 会在容器内运行该钩子。默认的 terminationGracePeriodSeconds 设置是 30 秒。

      如果在优雅终止期到期后 preStop 钩子仍在运行，kubelet 会请求一次性的小型优雅终止期延长，时长为 2 秒。

      注意

      如果 preStop 钩子完成所需时间比默认优雅终止期允许的时间长，你必须修改 terminationGracePeriodSeconds 来适应这种情况。

   2. kubelet 触发容器运行时向每个容器内的进程 1 发送 TERM 信号。

      如果 Pod 定义了任何 Sidecar 容器，则存在特殊的终止顺序。否则，Pod 中的容器会在不同的时间以任意顺序接收 TERM 信号。如果关机顺序很重要，考虑使用 preStop 钩子进行同步（或改为使用 Sidecar 容器）。

3. 在 kubelet 开始对 Pod 进行优雅关机的同时，控制平面评估是否将正在关机的 Pod 从 EndpointSlice 对象中移除，这些对象代表一个配置了选择器的Service。 ReplicaSet 和其他工作负载资源不再将正在关机的 Pod 视为有效的、正在提供服务的副本。

   缓慢关机的 Pod 不应继续处理常规流量，并且应开始终止并完成处理已打开的连接。有些应用需要做的不仅仅是完成已打开的连接，还需要更优雅的终止，例如会话排空和完成。

   代表正在终止的 Pod 的任何端点不会立即从 EndpointSlices 中移除，并且 EndpointSlice API 会暴露一个指示终止状态的状态。正在终止的端点的 ready 状态始终为 false（为了向后兼容 1.26 之前的版本），因此负载均衡器不会将其用于常规流量。

   如果需要在终止中的 Pod 上进行流量排空，可以将实际就绪状态作为条件 serving 进行检查。你可以在教程 Pod 和 Endpoint 终止流程 中找到关于如何实现连接排空的更多详细信息。

4. kubelet 确保 Pod 被关闭和终止。

   1. 当优雅终止期到期时，如果 Pod 中仍有容器正在运行，kubelet 会触发强制关机。容器运行时会向 Pod 中任何容器中仍在运行的任何进程发送 SIGKILL。如果容器运行时使用隐藏的 pause 容器，kubelet 也会清理该容器。
   2. kubelet 将 Pod 迁移到终端状态（Failed 或 Succeeded，取决于其容器的最终状态）。
   3. kubelet 通过将优雅终止期设置为 0（立即删除）来触发从 API 服务器中强制移除 Pod 对象。
   4. API 服务器删除 Pod 的 API 对象，该对象不再对任何客户端可见。

强制终止 Pod

默认情况下，所有删除操作都是优雅的，并在 30 秒内完成。kubectl delete 命令支持 --grace-period=<seconds> 选项，允许你覆盖默认值并指定自己的值。

将优雅终止期设置为 0 会强制并立即从 API 服务器中删除 Pod。如果 Pod 仍在节点上运行，该强制删除会触发 kubelet 立即开始清理。

使用 kubectl，你必须与 --grace-period=0 一起指定额外的标志 --force 来执行强制删除。

执行强制删除时，API 服务器不会等待 kubelet 确认 Pod 已在运行它的节点上终止。它会立即在 API 中删除 Pod，以便可以创建一个同名的新 Pod。在节点上，设置为立即终止的 Pod 在被强制终止之前仍会获得一个短暂的优雅终止期。

如果你需要强制删除 StatefulSet 的一部分 Pod，请参阅关于从 StatefulSet 中删除 Pod 的任务文档。

Pod 关闭和 Sidecar 容器

如果你的 Pod 包含一个或多个Sidecar 容器（具有 Always 重启策略的 Init 容器），kubelet 会延迟向这些 Sidecar 容器发送 TERM 信号，直到最后一个主容器完全终止。Sidecar 容器将按照它们在 Pod spec 中定义的逆序终止。这确保 Sidecar 容器继续为 Pod 中的其他容器提供服务，直到不再需要它们。

这意味着主容器的缓慢终止也会延迟 Sidecar 容器的终止。如果优雅终止期在终止过程完成之前到期，Pod 可能会进入强制终止。在这种情况下，Pod 中所有剩余的容器将以短暂的优雅终止期同时终止。

同样，如果 Pod 的 preStop 钩子超过了终止优雅终止期，可能会发生紧急终止。一般来说，如果你之前使用 preStop 钩子来控制没有 Sidecar 容器的终止顺序，你现在可以移除它们，让 kubelet 自动管理 Sidecar 终止。

Pod 的垃圾收集

对于失败的 Pod，其 API 对象保留在集群的 API 中，直到有人或控制器进程明确将其删除。

Pod 垃圾收集器（PodGC）是控制平面中的一个控制器，当 Pod 数量超过配置的阈值（由 kube-controller-manager 中的 terminated-pod-gc-threshold 确定）时，它会清理已终止的 Pod（状态为 Succeeded 或 Failed）。这避免了随着时间的推移创建和终止 Pod 造成的资源泄漏。

此外，PodGC 会清理满足以下任一条件的 Pod：

1. 是孤儿 Pod - 绑定到一个不再存在的节点上；
2. 是未调度的正在终止的 Pod；
3. 是正在终止的 Pod，绑定到一个带有node.kubernetes.io/out-of-service污点的非就绪节点。

除了清理 Pod 外，如果 Pod 处于非终端状态，PodGC 还会将其标记为失败。此外，PodGC 在清理孤儿 Pod 时会添加一个 Pod 异常状态条件。更多详情请参阅Pod 异常状态条件。

下一步

• 动手实践为容器生命周期事件附着处理程序。

• 动手实践配置存活、就绪和启动探针。

• 了解有关容器生命周期钩子的更多信息。

• 了解有关Sidecar 容器的更多信息。

• 有关 API 中 Pod 和容器状态的详细信息，请参阅描述 Pod 的status 的 API 参考文档。