Pod 生命周期
本页介绍了 Pod 的生命周期。Pod 遵循定义的生命周期,从 阶段 的 Pending
状态开始,如果至少一个主要容器启动成功,则转到 Running
状态,然后根据 Pod 中的任何容器是否在失败中终止,转到 Succeeded
或 Failed
阶段。
与单个应用程序容器一样,Pod 被认为是相对短暂的(而不是持久性的)实体。Pod 被创建,分配一个唯一的 ID (UID),并调度到节点上运行,它们将在那里保持运行,直到终止(根据重启策略)或删除。如果一个 节点 死亡,则运行在该节点上(或调度到该节点上运行)的 Pod 被 标记为删除。控制平面在超时后标记 Pod 以供删除。
Pod 生命周期
当 Pod 正在运行时,kubelet 能够重新启动容器以处理某些故障。在 Pod 内,Kubernetes 跟踪不同的容器 状态 并确定采取什么措施使 Pod 恢复健康。
在 Kubernetes API 中,Pod 既有规范也有实际状态。Pod 对象的状态包含一组 Pod 条件。如果对应用程序有用,您也可以将 自定义就绪信息 注入 Pod 的条件数据中。
Pod 仅在其生命周期中 调度 一次;将 Pod 分配给特定节点称为绑定,选择使用哪个节点的过程称为调度。一旦 Pod 被调度并绑定到一个节点,Kubernetes 就会尝试在该节点上运行该 Pod。Pod 在该节点上运行,直到它停止,或者直到 Pod 被 终止;如果 Kubernetes 无法在选定的节点上启动 Pod(例如,如果节点在 Pod 启动之前崩溃),那么该特定 Pod 就永远不会启动。
您可以使用 Pod 调度就绪 延迟调度 Pod,直到所有调度门都被移除。例如,您可能想要定义一组 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
的可能值
值 | 描述 |
---|---|
Pending | Pod 已被 Kubernetes 集群接受,但一个或多个容器尚未设置并准备就绪以运行。这包括 Pod 花费在等待调度上的时间,以及花费在通过网络下载容器镜像上的时间。 |
Running | Pod 已绑定到一个节点,并且所有容器都已创建。至少有一个容器仍在运行,或者正在启动或重新启动过程中。 |
Succeeded | Pod 中的所有容器都已成功终止,并且不会重新启动。 |
Failed | Pod 中的所有容器都已终止,并且至少有一个容器已在失败中终止。也就是说,容器要么以非零状态退出,要么被系统终止,并且未设置为自动重新启动。 |
Unknown | 由于某种原因,无法获取 Pod 的状态。此阶段通常由于与应运行 Pod 的节点通信时出现错误而发生。 |
注意
当 Pod 正在删除时,它将被某些 kubectl 命令显示为Terminating
。此 Terminating
状态不是 Pod 阶段之一。Pod 被授予一个时间段以优雅地终止,默认值为 30 秒。您可以使用标志 --force
强制终止 Pod。从 Kubernetes 1.27 开始,kubelet 会将已删除的 Pod(除了 静态 Pod 和没有最终化器的 强制删除的 Pod)转换为终止阶段(Failed
或 Succeeded
,具体取决于 Pod 容器的退出状态),然后将其从 API 服务器中删除。
如果一个节点死亡或与集群的其余部分断开连接,Kubernetes 会应用一个策略,将丢失节点上所有 Pod 的 phase
设置为 Failed。
容器状态
除了 Pod 的整体 阶段 之外,Kubernetes 还跟踪 Pod 内每个容器的状态。您可以使用 容器生命周期钩子 触发在容器生命周期的某些点运行的事件。
一旦 调度程序 将 Pod 分配给一个节点,kubelet 就会使用 容器运行时 开始为该 Pod 创建容器。有三种可能的容器状态:Waiting
、Running
和 Terminated
。
要检查 Pod 容器的状态,您可以使用 kubectl describe pod <name-of-pod>
。输出将显示该 Pod 中每个容器的状态。
每个状态都有特定的含义
Waiting
如果容器既不在 Running
状态也不在 Terminated
状态,则它处于 Waiting
状态。处于 Waiting
状态的容器仍在运行它需要完成启动的操作:例如,从容器镜像注册表中拉取容器镜像,或应用 密钥 数据。当您使用 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 如何对由于错误或其他原因而退出的容器做出反应,执行顺序如下:
- 初始崩溃:Kubernetes 会根据 Pod 的
restartPolicy
立即尝试重启。 - 重复崩溃:在初始崩溃之后,Kubernetes 会对后续重启应用指数级回退延迟,如
restartPolicy
中所述。这可以防止快速重复的重启尝试过载系统。 - CrashLoopBackOff 状态:这表示回退延迟机制当前正在针对处于崩溃循环中的给定容器生效,该容器反复失败并重启。
- 回退重置:如果容器成功运行了一定时间(例如 10 分钟),Kubernetes 将重置回退延迟,将任何新的崩溃视为第一次崩溃。
在实践中,CrashLoopBackOff
是一种状态或事件,当 Pod 中的容器无法正常启动,然后在循环中不断尝试并失败时,可能会在描述或列出 Pod 时作为 kubectl
命令的输出看到。
换句话说,当容器进入崩溃循环时,Kubernetes 会应用 容器重启策略 中提到的指数级回退延迟。这种机制可以防止有故障的容器因持续的失败启动尝试而压垮系统。
CrashLoopBackOff
可能由以下问题引起:
- 导致容器退出的应用程序错误。
- 配置错误,例如环境变量错误或缺少配置文件。
- 资源限制,容器可能没有足够的内存或 CPU 来正常启动。
- 如果应用程序没有在预期时间内开始提供服务,则健康检查会失败。
- 如 探测部分 所述,容器存活探测或启动探测返回
Failure
结果。
为了调查 CrashLoopBackOff
问题的根本原因,用户可以:
- 检查日志:使用
kubectl logs <name-of-pod>
检查容器的日志。这通常是诊断导致崩溃问题的最直接方法。 - 检查事件:使用
kubectl describe pod <name-of-pod>
查看 Pod 的事件,这些事件可以提供有关配置或资源问题的提示。 - 查看配置:确保 Pod 配置(包括环境变量和挂载卷)正确,并且所有必需的外部资源都可用。
- 检查资源限制:确保容器有足够的 CPU 和内存分配。有时,增加 Pod 定义中的资源可以解决问题。
- 调试应用程序:应用程序代码中可能存在错误或错误配置。在本地或开发环境中运行此容器镜像可以帮助诊断特定于应用程序的问题。
容器重启策略
Pod 的 spec
具有 restartPolicy
字段,其可能的值为 Always、OnFailure 和 Never。默认值为 Always。
Pod 的 restartPolicy
应用于 Pod 中的 应用程序容器 以及常规的 init 容器。 Sidecar 容器 会忽略 Pod 级别的 restartPolicy
字段:在 Kubernetes 中,sidecar 被定义为 initContainers
中的条目,其容器级别的 restartPolicy
设置为 Always
。对于以错误退出状态退出的 init 容器,如果 Pod 级别的 restartPolicy
为 OnFailure
或 Always
,则 kubelet 会重启 init 容器。
Always
:在任何终止后自动重启容器。OnFailure
:仅当容器以错误状态(非零退出状态)退出时才重启容器。Never
:不会自动重启已终止的容器。
当 kubelet 根据配置的重启策略处理容器重启时,这仅适用于在同一 Pod 中且在同一节点上运行的重启,这些重启会替换容器。在 Pod 中的容器退出后,kubelet 会以指数级回退延迟(10 秒、20 秒、40 秒……)重启它们,最大延迟为 300 秒(5 分钟)。一旦容器执行了 10 分钟且没有任何问题,kubelet 会重置该容器的重启回退计时器。 Sidecar 容器和 Pod 生命周期 解释了在 initContainers
上指定 restartpolicy
字段时的行为。
Pod 状态
Pod 具有 PodStatus,它包含一个 PodConditions 数组,通过该数组可以了解 Pod 是否已通过某个条件。kubelet 管理以下 PodConditions:
PodScheduled
:Pod 已调度到某个节点。PodReadyToStartContainers
:(beta 功能;由 默认 启用)Pod 沙箱已成功创建,并且已配置网络。ContainersReady
:Pod 中的所有容器都已就绪。Initialized
:所有 init 容器 已成功完成。Ready
:Pod 能够处理请求,应该添加到所有匹配服务的负载均衡池中。
字段名称 | 描述 |
---|---|
类型 | 此 Pod 条件的名称。 |
状态 | 指示该条件是否适用,可能的值为 "True "、"False " 或 "Unknown "。 |
lastProbeTime | 上次探测 Pod 条件的时间戳。 |
lastTransitionTime | Pod 上次从一种状态过渡到另一种状态的时间戳。 |
原因 | 机器可读的,以 UpperCamelCase 格式表示的文本,指示条件最后一次过渡的原因。 |
消息 | 人类可读的消息,指示有关最后一次状态过渡的详细信息。 |
Pod 就绪状态
Kubernetes v1.14 [稳定]
您的应用程序可以向 PodStatus 中注入额外的反馈或信号:Pod 就绪状态。要使用此功能,请在 Pod 的 spec
中设置 readinessGates
,以指定 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 就绪状态
kubectl patch
命令不支持修补对象状态。要设置这些 Pod 的 status.conditions
,应用程序和 操作符 应该使用 PATCH
操作。您可以使用 Kubernetes 客户端库 来编写设置 Pod 就绪状态的自定义 Pod 条件的代码。
对于使用自定义条件的 Pod,只有在以下两个语句都适用时,才会将其评估为已就绪:
- Pod 中的所有容器都已就绪。
readinessGates
中指定的所有条件都为True
。
当 Pod 的容器已就绪,但至少有一个自定义条件缺失或为 False
时,kubelet 会将 Pod 的 条件 设置为 ContainersReady
。
Pod 网络就绪状态
Kubernetes v1.29 [beta]
注意
在早期开发阶段,该条件名为PodHasNetwork
。在 Pod 被调度到某个节点后,它需要被 kubelet 接收,并且需要挂载所有必需的存储卷。一旦这些阶段完成,kubelet 就会与容器运行时(使用 容器运行时接口 (CRI))协作,为 Pod 设置运行时沙箱并配置网络。如果 PodReadyToStartContainersCondition
功能门 已启用(对于 Kubernetes 1.31,它默认启用),则 PodReadyToStartContainers
条件将被添加到 Pod 的 status.conditions
字段中。
当 kubelet 检测到 Pod 没有配置了网络的运行时沙箱时,PodReadyToStartContainersCondition
条件将被 kubelet 设置为 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
。
容器探测
探测 是 kubelet 定期对容器执行的一种诊断操作。为了执行诊断操作,kubelet 可以在容器内执行代码,或者进行网络请求。
检查机制
有四种不同的方法可以使用探测来检查容器。每个探测必须定义这四种机制中的一种:
exec
- 在容器内执行指定的命令。如果命令以 0 的状态代码退出,则诊断操作被认为成功。
grpc
- 使用 gRPC 执行远程过程调用。目标应实现 gRPC 健康检查。如果响应的
status
为SERVING
,则诊断操作被认为成功。 httpGet
- 对 Pod 的 IP 地址上的指定端口和路径执行 HTTP
GET
请求。如果响应的状态代码大于或等于 200,小于 400,则诊断操作被认为成功。 tcpSocket
- 对 Pod 的 IP 地址上的指定端口执行 TCP 检查。如果端口已打开,则诊断操作被认为成功。如果远程系统(容器)在打开连接后立即关闭连接,则这算作健康状态。
注意事项
与其他机制不同的是,exec
探测的实现每次执行时都会涉及多个进程的创建/派生。因此,对于具有更高 Pod 密度的集群,initialDelaySeconds
和 periodSeconds
的间隔更低,使用 exec
机制配置任何探测可能会给节点的 CPU 使用率带来开销。在这种情况下,请考虑使用替代的探测机制来避免开销。探测结果
每个探测都有三种结果之一:
成功
- 容器通过了诊断操作。
失败
- 容器诊断失败。
Unknown
- 诊断失败(无需采取任何措施,kubelet 会进行进一步检查)。
探针类型
kubelet 可以选择性地对正在运行的容器执行三种探针并做出反应
livenessProbe
- 指示容器是否正在运行。如果 liveness 探针失败,kubelet 将杀死容器,容器将受到其重启策略的影响。如果容器没有提供 liveness 探针,则默认状态为
Success
。 readinessProbe
- 指示容器是否已准备好响应请求。如果 readiness 探针失败,端点控制器将从与 Pod 匹配的所有服务的端点中删除 Pod 的 IP 地址。在初始延迟之前,readiness 的默认状态为
Failure
。如果容器没有提供 readiness 探针,则默认状态为Success
。 startupProbe
- 指示容器内的应用程序是否已启动。如果提供了启动探针,则所有其他探针都将被禁用,直到它成功。如果启动探针失败,kubelet 将杀死容器,容器将受到其重启策略的影响。如果容器没有提供启动探针,则默认状态为
Success
。
有关如何设置 liveness、readiness 或启动探针的更多信息,请参阅配置 Liveness、Readiness 和启动探针。
何时使用 liveness 探针?
如果容器中的进程能够在遇到问题或变得不健康时自行崩溃,则您可能不需要 liveness 探针;kubelet 会根据 Pod 的restartPolicy
自动执行正确的操作。
如果您希望在探针失败时杀死并重启容器,请指定 liveness 探针,并指定restartPolicy
为 Always 或 OnFailure。
何时使用 readiness 探针?
如果您希望仅在探针成功时才开始向 Pod 发送流量,请指定 readiness 探针。在这种情况下,readiness 探针可能与 liveness 探针相同,但规范中 readiness 探针的存在意味着 Pod 将在不接收任何流量的情况下启动,并且仅在探针开始成功后才开始接收流量。
如果您希望容器能够自行停机进行维护,您可以指定一个 readiness 探针,该探针检查一个与 liveness 探针不同的、特定于 readiness 的端点。
如果您的应用程序严格依赖于后端服务,您可以同时实现 liveness 和 readiness 探针。当应用程序本身健康时,liveness 探针通过,但 readiness 探针还会检查每个必需的后端服务是否可用。这有助于您避免将流量定向到只能响应错误消息的 Pod。
如果您的容器需要在启动期间处理大型数据、配置文件或迁移,您可以使用启动探针。但是,如果您想检测已失败的应用程序与仍在处理启动数据的应用程序之间的区别,您可能更喜欢 readiness 探针。
注意
如果您希望能够在删除 Pod 时排空请求,则您可能不需要 readiness 探针;删除时,Pod 会自动进入不就绪状态,无论 readiness 探针是否存在。Pod 保持不就绪状态,同时等待 Pod 中的容器停止。何时使用启动探针?
启动探针对于具有需要很长时间才能投入服务的容器的 Pod 很有用。您可以配置一个单独的配置来探测容器启动时的状态,而不是设置一个较长的 liveness 间隔,这将允许比 liveness 间隔允许的时间更长的时间。
如果您的容器通常在超过initialDelaySeconds + failureThreshold × periodSeconds
的时间内启动,则应指定一个启动探针来检查与 liveness 探针相同的端点。periodSeconds
的默认值为 10 秒。然后,您应该将其failureThreshold
设置得足够高,以允许容器启动,而不更改 liveness 探针的默认值。这有助于防止死锁。
Pod 终止
由于 Pod 代表在集群节点上运行的进程,因此允许这些进程在不再需要时优雅地终止(而不是被KILL
信号突然停止,并且没有机会进行清理)非常重要。
设计目标是能够请求删除并知道进程何时终止,但也能够确保删除最终完成。当您请求删除 Pod 时,集群会记录并跟踪 Pod 允许被强制杀死之前的预期宽限期。有了这种强制关闭跟踪到位后,kubelet 会尝试进行优雅关闭。
通常,通过这种对 Pod 的优雅终止,kubelet 会向容器运行时发出请求,尝试通过首先向每个容器中的主进程发送 TERM(又称 SIGTERM)信号(带有宽限期超时)来停止 Pod 中的容器。停止容器的请求由容器运行时异步处理。这些请求的处理顺序没有保证。许多容器运行时尊重容器映像中定义的STOPSIGNAL
值,并且如果不同,则发送容器映像配置的 STOPSIGNAL 而不是 TERM。宽限期到期后,KILL 信号将发送到任何剩余的进程,然后 Pod 将从API Server 中删除。如果 kubelet 或容器运行时的管理服务在等待进程终止时重新启动,则集群将从头开始重试,包括完整的原始宽限期。
Pod 终止流程,用示例说明
您使用
kubectl
工具手动删除特定 Pod,使用默认宽限期(30 秒)。API 服务器中的 Pod 将更新为 Pod 被视为“已死”的时间以及宽限期。如果您使用
kubectl describe
检查要删除的 Pod,该 Pod 将显示为“正在终止”。在 Pod 运行的节点上:一旦 kubelet 看到 Pod 已被标记为正在终止(已设置优雅关闭持续时间),kubelet 将开始本地 Pod 关闭过程。如果 Pod 的某个容器定义了
preStop
钩子,并且 Pod 规范中的terminationGracePeriodSeconds
未设置为 0,kubelet 将在容器内运行该钩子。默认的terminationGracePeriodSeconds
设置为 30 秒。如果
preStop
钩子在宽限期到期后仍在运行,kubelet 将请求一个小的、一次性的宽限期扩展(2 秒)。注意
如果preStop
钩子需要比默认宽限期允许的时间更长才能完成,您必须修改terminationGracePeriodSeconds
以适应这一点。kubelet 触发容器运行时向每个容器内的进程 1 发送 TERM 信号。
如果 Pod 定义了任何边车容器,则存在特殊排序。否则,Pod 中的容器将在不同的时间和任意顺序接收 TERM 信号。如果关闭顺序很重要,请考虑使用
preStop
钩子进行同步(或切换到使用边车容器)。
与 kubelet 开始 Pod 的优雅关闭同时,控制平面会评估是否从 EndpointSlice(和 Endpoints)对象中删除正在关闭的 Pod,其中这些对象代表具有配置的服务选择器。ReplicaSets 和其他工作负载资源不再将正在关闭的 Pod 视为有效的在服务副本。
关闭缓慢的 Pod 不应继续提供常规流量,并且应开始终止并完成处理打开的连接。一些应用程序需要超越完成打开的连接,并且需要更优雅的终止,例如会话排空和完成。
代表正在终止的 Pod 的任何端点不会立即从 EndpointSlices 中删除,并且 EndpointSlice API(以及旧的 Endpoints API)会公开一个指示终止状态的状态。终止的端点始终将其
ready
状态设置为false
(为了与 1.26 之前的版本向后兼容),因此负载均衡器不会将其用于常规流量。如果需要对正在终止的 Pod 进行流量排空,则可以将实际的 readiness 检查为条件
serving
。您可以在教程Pod 和端点终止流程中找到有关如何实现连接排空的更多详细信息。
强制 Pod 终止
默认情况下,所有删除都在 30 秒内是优雅的。kubectl delete
命令支持--grace-period=<seconds>
选项,该选项允许您覆盖默认值并指定您自己的值。
将宽限期设置为0
将立即从 API 服务器中强制删除 Pod。如果 Pod 仍在节点上运行,强制删除将触发 kubelet 开始立即清理。
使用 kubectl,您必须在--grace-period=0
之前指定一个附加标志--force
才能执行强制删除。
如果您需要强制删除属于 StatefulSet 的 Pod,请参阅从 StatefulSet 中删除 Pod的任务文档。
Pod 关闭和边车容器
如果您的 Pod 包含一个或多个 边车容器(具有 Always 重启策略的 init 容器),kubelet 会延迟向这些边车容器发送 TERM 信号,直到最后一个主容器完全终止。边车容器将按照它们在 Pod 规范中定义的相反顺序终止。这样可以确保边车容器继续为 Pod 中的其他容器提供服务,直到不再需要它们。
这意味着主容器的缓慢终止也会延迟边车容器的终止。如果在终止过程完成之前宽限期到期,Pod 可能会进入 强制终止 状态。在这种情况下,Pod 中所有剩余的容器将在一个短暂的宽限期内同时终止。
类似地,如果 Pod 具有超过终止宽限期的 preStop
钩子,则可能发生紧急终止。总的来说,如果您使用 preStop
钩子来控制没有边车容器的终止顺序,现在可以删除它们并允许 kubelet 自动管理边车终止。
Pod 垃圾回收
对于失败的 Pod,API 对象会保留在集群的 API 中,直到人工或 控制器 进程显式将其删除。
Pod 垃圾回收器(PodGC)是控制平面中的一个控制器,它清理已终止的 Pod(处于 Succeeded
或 Failed
阶段),当 Pod 的数量超过配置的阈值(由 kube-controller-manager 中的 terminated-pod-gc-threshold
确定)时。这可以避免随着时间的推移创建和终止 Pod 导致的资源泄漏。
此外,PodGC 会清理满足以下任何条件的 Pod
- 是孤儿 Pod - 绑定到不再存在的节点,
- 是未调度正在终止的 Pod,
- 是正在终止的 Pod,绑定到带有
node.kubernetes.io/out-of-service
污点的非就绪节点,当NodeOutOfServiceVolumeDetach
功能门打开时。
除了清理 Pod 外,PodGC 还会在清理孤儿 Pod 时将其标记为失败。此外,PodGC 在清理孤儿 Pod 时会添加 Pod 中断条件。有关更多详细信息,请参阅 Pod 中断条件。
下一步
动手体验 将处理程序附加到容器生命周期事件。
动手体验 配置存活探针、就绪探针和启动探针。
详细了解 容器生命周期钩子。
详细了解 边车容器。
有关 API 中 Pod 和容器状态的详细信息,请参阅涵盖
status
的 API 参考文档。