` 查看 Pod 的事件，
这可以提供有关配置或资源问题的提示。
1. **审查配置**：确保 Pod 配置正确无误，包括环境变量和挂载卷，并且所有必需的外部资源都可用。
1. **检查资源限制**： 确保容器被分配了足够的 CPU 和内存。有时，增加 Pod 定义中的资源可以解决问题。
1. **调试应用程序**：应用程序代码中可能存在错误或配置不当。
在本地或开发环境中运行此容器镜像有助于诊断应用程序的特定问题。
### 容器重启 {#restart-policy}
当 Pod 中的某个容器停止或发生故障时，Kubernetes 可以重新启动此容器。但重启并不总是合适的；例如，
Init 容器只在 Pod 启动期间运行一次（如果成功）。
你可以将重启配置为适用于所有 Pod 的策略，或者使用容器级别的配置（例如：
在你定义边车容器或定义容器级别重载时）。
#### 容器重启与弹性 {#container-restart-resilience}
Kubernetes 项目建议遵循云原生原则，包括能够应对未预告或随意重启的弹性设计。
你可以通过让 Pod 失败并依赖自动[替换](/zh-cn/docs/concepts/workloads/controllers/)，
或者通过容器级别的弹性设计来实现。
无论哪种方式，都有助于确保即使在部分故障的情况下，你的整体工作负载依然保持可用。
### Pod 级别容器重启策略
Pod 的 `spec` 中包含一个 `restartPolicy` 字段，其可能取值包括
Always、OnFailure 和 Never。默认值是 Always。
`restartPolicy` 应用于 Pod
中的应用容器和常规的
[Init 容器](/zh-cn/docs/concepts/workloads/pods/init-containers/)。
[Sidecar 容器](/zh-cn/docs/concepts/workloads/pods/sidecar-containers/)忽略
Pod 级别的 `restartPolicy` 字段：在 Kubernetes 中，Sidecar 被定义为
`initContainers` 内的一个条目，其容器级别的 `restartPolicy` 被设置为 `Always`。
对于因错误而退出的 Init 容器，如果 Pod 级别 `restartPolicy` 为 `OnFailure` 或 `Always`，
则 kubelet 会重新启动 Init 容器。
* `Always`：只要容器终止就自动重启容器。
* `OnFailure`：只有在容器错误退出（退出状态非零）时才重新启动容器。
* `Never`：不会自动重启已终止的容器。
##### 重启行为比较
下表显示了在不同的重启策略和退出代码下容器的行为：
| 退出代码 | `restartPolicy: Always` | `restartPolicy: OnFailure` | `restartPolicy: Never` | 边车容器 |
|-----------|-------------------------|---------------------------|------------------------|---------------|
| 0 （成功） | 重启 | 不重启 | 不重启 | 总是重启 |
| 非零 （失败） | 重启 | 重启 | 不重启 | 总是重启 |
说明：
在选择 Deployment 还是 Job 时，重启行为尤为重要：
- Deployment 通常使用
restartPolicy: Always（唯一允许的值）来保持应用程序持续运行。
- Job 通常使用
restartPolicy: OnFailure 或 restartPolicy: Never 来妥善处理批处理作业。
- 边车容器是初始化容器，无论 Pod 的
restartPolicy 设置如何，
它们都会始终重启，因为它们拥有自己的容器级 restartPolicy: Always 设置。
说明：
虽然主应用程序容器遵循 Pod 的 restartPolicy: OnFailure，
但边车容器无论其退出代码如何都会重新启动，因为边车容器在容器级别会始终设置
restartPolicy: Always。
特性状态：
Kubernetes v1.35 [beta]（默认启用）
如果你的集群启用了 `ContainerRestartRules` 特性门控，你可以针对**单个容器**指定
`restartPolicy` 和 `restartPolicyRules` 来覆盖 Pod 重启策略。容器重启策略和规则适用于 Pod
中的应用容器以及常规的
[Init 容器](/zh-cn/docs/concepts/workloads/pods/init-containers/)。
Kubernetes 原生的[边车容器](/zh-cn/docs/concepts/workloads/pods/sidecar-containers/)将其容器级别的
`restartPolicy` 设置为 `Always`。
容器重启会遵循与前文所述的 Pod 重启策略相同的指数回退机制。支持的容器重启策略有：
* `Always`：在任何原因的容器终止后都会自动重启容器。
* `OnFailure`：仅当容器因错误退出（非零退出状态）时才重启。
* `Never`：不自动重启已终止的容器。
此外，**单个容器**可以指定 `restartPolicyRules`。如果指定了 `restartPolicyRules` 字段，
则**必须**同时指定容器的 `restartPolicy`。`restartPolicyRules` 定义了一系列在容器退出时应用的规则。
每条规则由条件和动作组成。支持的条件是 `exitCodes`，用于将容器的退出码与给定值列表进行比较。
支持的动作是 `Restart`，表示容器将被重启。这些规则会按顺序进行评估。一旦匹配成功，立即执行相应动作。
如果没有任何规则的状况被匹配，Kubernetes 回退到容器配置的 `restartPolicy`。
例如，重启策略为 OnFailure 的某个 Pod 包含一个 `try-once` 容器。
这样可以让 Pod 仅重启某些容器：
```yaml
apiVersion: v1
kind: Pod
metadata:
name: on-failure-pod
spec:
restartPolicy: OnFailure
containers:
- name: try-once-container # 此容器只运行一次，因为 restartPolicy 设置为 Never。
image: registry.k8s.io/busybox:1.27.2
command: ['sh', '-c', 'echo "Only running once" && sleep 10 && exit 1']
restartPolicy: Never
- name: on-failure-container # 此容器将在失败时重启。
image: registry.k8s.io/busybox:1.27.2
command: ['sh', '-c', 'echo "Keep restarting" && sleep 1800 && exit 1']
```
下面是一个重启策略为 `Always` 的 Pod，其中包含一个只执行一次的 Init 容器。
如果 Init 容器失败，则 Pod 也会失败。
这样可以在初始化失败时让 Pod 失败，但在初始化成功后保持 Pod 运行：
```yaml
apiVersion: v1
kind: Pod
metadata:
name: fail-pod-if-init-fails
spec:
restartPolicy: Always
initContainers:
- name: init-once # 这个 Init 容器只尝试一次。如果失败，Pod 将失败。
image: registry.k8s.io/busybox:1.27.2
command: ['sh', '-c', 'echo "Failing initialization" && sleep 10 && exit 1']
restartPolicy: Never
containers:
- name: main-container # 一旦初始化成功，此容器会始终被重启。
image: registry.k8s.io/busybox:1.27.2
command: ['sh', '-c', 'sleep 1800 && exit 0']
```
下面是一个重启策略为 Never 的 Pod，其中包含的容器会在遇到特定的退出码时忽略之并重启。
这种配置有助于区分可重启错误和不可重启错误：
```yaml
apiVersion: v1
kind: Pod
metadata:
name: restart-on-exit-codes
spec:
restartPolicy: Never
containers:
- name: restart-on-exit-codes
image: registry.k8s.io/busybox:1.27.2
command: ['sh', '-c', 'sleep 60 && exit 0']
restartPolicy: Never # 如果指定了规则，必须同时指定容器重启策略
restartPolicyRules: # 仅当退出码为 42 时才重启容器
- action: Restart
exitCodes:
operator: In
values: [42]
```
重启规则可用于许多其他高级的生命周期管理场景。
需要注意的是，重启规则会受到不一致性影响，这一点上与常规的重启策略相同。
kubelet 重启、容器运行时垃圾收集、与控制平面的间歇性连接问题都可能导致状态丢失，
容器可能会在你预期不应被重启的情况下被再次运行。
#### 重启所有容器 {#restart-all-containers}
特性状态：
Kubernetes v1.36 [beta]（默认启用）
如果你的集群已启用特性门控 `RestartAllContainersOnContainerExits`，
你可以在容器级别的 `restartPolicyRules` 中指定 `RestartAllContainers` 作为一个动作。
当容器的退出符合包含此动作的某个规则时，整个 Pod 被终止并就地重启。
这种“就地”重启比完全删除并重新创建 Pod 提供了更高效的方式来重置 Pod 的状态。
这对于调度批处理作业或 AI/ML 训练任务这类开销高的工作负载尤其有价值。
##### 就地重启 Pod 的工作原理
当触发 `RestartAllContainers` 动作时，kubelet 执行以下步骤：
1. **快速终止**：Pod 中所有正在运行的容器被终止。
配置的 `terminationGracePeriodSeconds` 不会生效，配置的所有
`preStop` 回调也不会被执行。这样可以确保快速关闭容器。
2. **保留 Pod 资源**：Pod 的关键资源被保留：
* Pod UID、IP 地址和网络命名空间
* Pod 沙箱及所挂接的所有设备
* 所有卷，包括 `emptyDir` 和挂载卷
3. **更新 Pod 状态**：Pod 的状态被更新，同时 `PodRestartInPlace` 状况设置为 `True`，使重启过程可观测。
4. **完整重启序列**：当所有容器终止后，将 `PodRestartInPlace` 状况设置为 `False`，然后 Pod 开始标准的启动流程：
* **Init 容器按顺序重新运行**。
* 边车和普通容器启动。
此特性的一个关键点是**所有**容器都会被重启，包括之前已成功完成或失败的容器。
`RestartAllContainers` 动作会重载所有已配置的容器级或 Pod 级别的 `restartPolicy`。
这种机制在需要为所有容器提供干净环境的场景中非常有用，例如：
- 当 Init 容器设置的环境可能被破坏时，此特性确保重新执行此设置过程。
- 边车容器可以监控主应用的健康状态，如果该应用进入不可恢复的状态，则触发整个 Pod 重启。
考虑一种工作负载，其中 watcher 边车负责在主应用出错时从已知良好状态重启主应用。
watcher 可以以特定代码退出，从而触发 worker Pod 的就地完整重启。
apiVersion: v1
kind: Pod
metadata:
name: ml-worker
spec:
restartPolicy: Never # Pod 本身不会自动重启，除非被显式指定。
initContainers:
- name: setup-environment
image: registry.k8s.io/busybox:1.27.2
command: ['sh', '-c', 'echo "Setting up environment"']
# 这个 Init 容器只运行一次，用于准备环境。
# 在触发 RestartAllContainers 动作后，此容器会再次运行。
- name: watcher-sidecar
image: registry.k8s.io/busybox:1.27.2
# 在真实场景中，这里通常会使用一个专用的 watcher 镜像。
# 此命令用于模拟 watcher 以特定的退出码退出。
command: ['sh', '-c', 'sleep 60; exit 88']
restartPolicy: Always
restartPolicyRules:
- action: RestartAllContainers
onExit:
exitCodes:
# 退出码 88 会触发整个 Pod 的完全重启。
operator: In
values: [88]
containers:
- name: main-application
image: registry.k8s.io/busybox:1.27.2
command: ['sh', '-c', 'echo "Application is running"; sleep 3600']
在此示例中：
- Pod 的整体 `restartPolicy` 为 `Never`。
- `watcher-sidecar` 执行命令后以退出码 `88` 退出。
- 退出码符合规则，触发 `RestartAllContainers` 动作。
- 整个 Pod（包括 `setup-environment` init 容器和 `main-application` 容器）随后就地重启。
Pod 保留其 UID、沙箱、IP 和卷。
### 减少容器重启延迟 {#Reduced-container-restart-delay}
特性状态：
Kubernetes v1.33 [alpha]（默认禁用）
启用 Alpha 特性开关 `ReduceDefaultCrashLoopBackOffDecay` 后，
集群中容器启动重试的初始延迟将从 10 秒减少到 1 秒，
之后每次重启延迟时间按 2 倍指数增长，直到达到最大延迟 60 秒（之前为 300 秒，即 5 分钟）。
如果你同时使用了下面介绍的 Alpha 特性 `KubeletCrashLoopBackOffMax`，
那么单个节点上可能会有不同的最大延迟值。
### 可配置的容器重启延迟 {#configurable-container-restart-delay}
特性状态：
Kubernetes v1.35 [beta]（默认启用）
启用特性门控 `KubeletCrashLoopBackOffMax` 后，
你可以重新配置容器启动重试之间的最大延迟，默认值为 300 秒（5 分钟）。
此配置是针对每个节点使用 kubelet 配置进行设置的。
在你的 [kubelet 配置](/zh-cn/docs/tasks/administer-cluster/kubelet-config-file/)中，
在 `crashLoopBackOff` 下设置 `maxContainerRestartPeriod` 字段，取值范围在 `"1s"` 到 `"300s"` 之间。
如上文[容器重启策略](#restart-policy)所述，该节点上的延迟仍将从 10 秒开始，并在每次重启后以指数方式增加
2 倍，但现在其上限将被限制为你所配置的最大值。如果你配置的 `maxContainerRestartPeriod` 小于默认初始值 10 秒，
则初始延迟将被设置为配置的最大值。
参见以下 kubelet 配置示例：
```yaml
# 容器重启延迟将从 10 秒开始，每次重启增加 2 倍
# 最高达到 100 秒
kind: KubeletConfiguration
crashLoopBackOff:
maxContainerRestartPeriod: "100s"
```
```yaml
# 容器重启之间的延迟将始终为 2 秒
kind: KubeletConfiguration
crashLoopBackOff:
maxContainerRestartPeriod: "2s"
```
如果你将此特性与上文提到的 Alpha 特性 `ReduceDefaultCrashLoopBackOffDecay` 一起使用，
那么集群的初始退避时间和最大退避时间默认值将不再是 10 秒和 300 秒，而是 1 秒和 60 秒。
每个节点上的配置优先于 `ReduceDefaultCrashLoopBackOffDecay` 所设置的默认值，
即使这会导致某些节点的最大退避时间比集群中的其他节点更长。
## Pod 状况 {#pod-conditions}
Pod 有一个 PodStatus 对象，其中包含一个
[PodConditions](/docs/reference/generated/kubernetes-api/v1.36/#podcondition-v1-core)
数组。Pod 可能通过也可能未通过其中的一些状况测试。
Kubelet 管理以下 PodCondition：
* `PodScheduled`：Pod 已经被调度到某节点；
* `PodReadyToStartContainers`：Pod 沙箱被成功创建并且配置了网络（Beta 特性，[默认](#pod-has-network)启用）；
* `ContainersReady`：Pod 中所有容器都已就绪；
* `Initialized`：所有的 [Init 容器](/zh-cn/docs/concepts/workloads/pods/init-containers/)都已成功完成；
* `Ready`：Pod 可以为请求提供服务，并且应该被添加到对应服务的负载均衡池中。
* `DisruptionTarget`：由于干扰（例如抢占、驱逐或垃圾回收），Pod 即将被终止。
* `PodResizePending`：已请求对 Pod 进行调整大小，但尚无法应用。
详见 [Pod 调整大小状态](/zh-cn/docs/tasks/configure-pod-container/resize-container-resources#pod-resize-status)。
* `PodResizeInProgress`：Pod 正在调整大小中。
详见 [Pod 调整大小状态](/zh-cn/docs/tasks/configure-pod-container/resize-container-resources#pod-resize-status)。
字段名称 | 描述
:--------------------|:-----------
`type` | Pod 状况的名称
`status` | 表明该状况是否适用，可能的取值有 "`True`"、"`False`" 或 "`Unknown`"
`lastProbeTime` | 上次探测 Pod 状况时的时间戳
`lastTransitionTime` | Pod 上次从一种状态转换到另一种状态时的时间戳
`reason` | 机器可读的、驼峰编码（UpperCamelCase）的文字，表述上次状况变化的原因
`message` | 人类可读的消息，给出上次状态转换的详细信息
### Pod 就绪态 {#pod-readiness-gate}
特性状态：
Kubernetes v1.29 [beta]
你的应用可以向 PodStatus 中注入额外的反馈或者信号：**Pod Readiness（Pod 就绪态）**。
要使用这一特性，可以设置 Pod 规约中的 `readinessGates` 列表，为 kubelet
提供一组额外的状况供其评估 Pod 就绪态时使用。
就绪态门控基于 Pod 的 `status.conditions` 字段的当前值来做决定。
如果 Kubernetes 无法在 `status.conditions` 字段中找到某状况，
则该状况的状态值默认为 "`False`"。
这里是一个例子：
```yaml
kind: Pod
...
spec:
readinessGates:
- conditionType: "www.example.com/feature-1"
status:
conditions:
- type: Ready # 内置的 Pod 状况
status: "False"
lastProbeTime: null
lastTransitionTime: 2018-01-01T00:00:00Z
- type: "www.example.com/feature-1" # 额外的 Pod 状况
status: "False"
lastProbeTime: null
lastTransitionTime: 2018-01-01T00:00:00Z
containerStatuses:
- containerID: docker://abcd...
ready: true
...
```
你所添加的 Pod 状况名称必须满足 Kubernetes
[标签键名格式](/zh-cn/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)。
### Pod 就绪态的状态 {#pod-readiness-status}
命令 `kubectl patch` 不支持修改对象的状态。
如果需要设置 Pod 的 `status.conditions`，应用或者
Operators
需要使用 `PATCH` 操作。你可以使用
[Kubernetes 客户端库](/zh-cn/docs/reference/using-api/client-libraries/)之一来编写代码，
针对 Pod 就绪态设置定制的 Pod 状况。
对于使用定制状况的 Pod 而言，只有当下面的陈述都适用时，该 Pod 才会被评估为就绪：
* Pod 中所有容器都已就绪；
* `readinessGates` 中的所有状况都为 `True` 值。
当 Pod 的容器都已就绪，但至少一个定制状况没有取值或者取值为 `False`，
`kubelet` 将 Pod 的[状况](#pod-conditions)设置为 `ContainersReady`。
### Pod 网络就绪 {#pod-has-network}
特性状态：
Kubernetes v1.25 [alpha]
说明：
在其早期开发过程中，这种状况被命名为 PodHasNetwork。
特性状态：
Kubernetes v1.35 [stable]（默认启用）
Kubernetes 支持在 Pod 创建后更改分配给 Pod 的 CPU 和内存资源。
（对于其他基础设施资源，你需要使用特定于这些资源的不同技术。）
调整 CPU 和内存资源主要有两种方法：
### 原地 Pod 调整大小 {#pod-resize-inplace}
你可以调整 Pod 的容器级别 CPU 和内存资源，而无需重建 Pod。
这亦被称为**原地 Pod 垂直扩缩**。这允许你在可能避免应用程序中断的同时，
调整运行容器的资源配置。
要执行原地调整大小，你可以使用 `/resize` 子资源更新 Pod 的期望状态。
然后，kubelet 会尝试将新的资源值应用到运行中的容器。
Pod 状况
`PodResizePending` 和 `PodResizeInProgress` （在 [Pod 状况](#pod-conditions) 中描述）
指示调整大小操作的状态。有关调整大小状态的更多详情，请参见
[容器调整大小状态](/zh-cn/docs/tasks/configure-pod-container/resize-container-resources/#container-resize-status)。
就地调整大小的关键考量：
- 仅 CPU 和内存资源可以原地调整大小。
- Pod 的[服务质量（QoS）类](/zh-cn/docs/concepts/workloads/pods/pod-qos/)在创建时确定，
且不能通过调整大小来更改。
- 你可以使用容器规约中的 `resizePolicy` 配置是否需要重启容器以进行调整大小。
有关执行原地调整大小的详细说明，
请参见[调整分配给容器的 CPU 和内存资源](/zh-cn/docs/tasks/configure-pod-container/resize-container-resources/)。
### 通过启动替代 Pod 进行调整大小
更改 Pod 资源更云原生的方法是通过管理它的工作负载资源（如 Deployment 或 StatefulSet）。
当你更新 Pod 模板中的资源规约时，
工作负载的控制器会根据其更新策略创建具有更新资源的新 Pod 并终止旧 Pod。
这种方法：
- 适用于任何 Kubernetes 版本。
- 可以更改任何 Pod 规约，而不仅仅是资源。
- 会导致 Pod 替换，因此你应该设计你的工作负载来处理[计划内的干扰](/zh-cn/docs/concepts/workloads/pods/disruptions/)。
考虑使用 [PodDisruptionBudget](/zh-cn/docs/tasks/run-application/configure-pdb/)
来控制可用性。
- 要求你的 Pod 由工作负载资源管理。
你也可以使用
[VerticalPodAutoscaler](/zh-cn/docs/concepts/workloads/autoscaling/vertical-pod-autoscale/)
来自动管理 Pod 资源建议和更新。
## 容器探针 {#container-probes}
**probe** 是由 [kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/) 对容器执行的定期诊断。
要执行诊断，kubelet 既可以在容器内执行代码，也可以发出一个网络请求。
### 检查机制 {#probe-check-methods}
使用探针来检查容器有四种不同的方法。
每个探针都必须准确定义为这四种机制中的一种：
`exec`
: 在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
`grpc`
: 使用 [gRPC](https://grpc.io/) 执行一个远程过程调用。
目标应该实现
[gRPC 健康检查](https://grpc.io/grpc/core/md_doc_health-checking.html)。
如果响应的状态是 "SERVING"，则认为诊断成功。
`httpGet`
: 对容器的 IP 地址上指定端口和路径执行 HTTP `GET` 请求。如果响应的状态码大于等于 200
且小于 400，则诊断被认为是成功的。有关 kubelet 如何跟踪重定向的更多信息，
请参阅[配置探测](/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#http-probes)。
`tcpSocket`
: 对容器的 IP 地址上的指定端口执行 TCP 检查。如果端口打开，则诊断被认为是成功的。
如果远程系统（容器）在打开连接后立即将其关闭，这算作是健康的。
注意：
和其他机制不同，exec 探针的实现涉及每次执行时创建/复制多个进程。
因此，在集群中具有较高 pod 密度、较低的 initialDelaySeconds 和 periodSeconds 时长的时候，
配置任何使用 exec 机制的探针可能会增加节点的 CPU 负载。
这种场景下，请考虑使用其他探针机制以避免额外的开销。
说明：
请注意，如果你只是想在 Pod 被删除时能够排空请求，则不一定需要使用就绪态探针；
当 Pod 被删除时，EndpointSlice 中对应的端点会更新其状况：
该端点的 ready 状况将被设置为 false，因此负载均衡器不会再将该 Pod 用于常规流量。
关于 kubelet 如何处理 Pod 删除的更多信息，请参见 Pod 终止。
特性状态：
Kubernetes v1.33 [alpha]（默认禁用）
如果启用了 `ContainerStopSignals` 特性门控（feature gate），
你可以通过容器的生命周期（Lifecycle）配置自定义的终止信号。
在容器生命周期中定义终止信号时，Pod 的 `spec.os.name` 字段必须存在。
可用的信号列表取决于 Pod 调度到的操作系统。
对于调度到 Windows 节点的 Pod，仅支持 SIGTERM 和 SIGKILL 信号。
以下是一个定义了自定义终止信号的 Pod 示例：
```yaml
spec:
os:
name: linux
containers:
- name: my-container
image: container-image:latest
lifecycle:
stopSignal: SIGUSR1
```
如果在生命周期中定义了终止信号，则会覆盖容器镜像中定义的信号。
如果容器规约中未定义终止信号，则容器将回退到默认行为。
### Pod 终止流程 {#pod-termination-flow}
Pod 终止流程，如下例所示：
1. 你使用 `kubectl` 工具手动删除某个特定的 Pod，而该 Pod 的体面终止限期是默认值（30 秒）。
2. API 服务器中的 Pod 对象被更新，记录涵盖体面终止限期在内 Pod
的最终死期，超出所计算时间点则认为 Pod 已死（dead）。
如果你使用 `kubectl describe` 来查验你正在删除的 Pod，该 Pod 会显示为
"Terminating" （正在终止）。
在 Pod 运行所在的节点上：`kubelet` 一旦看到 Pod
被标记为正在终止（已经设置了体面终止限期），`kubelet` 即开始本地的 Pod 关闭过程。
1. 如果 Pod 中的容器之一定义了 `preStop`
[回调](/zh-cn/docs/concepts/containers/container-lifecycle-hooks)
且 Pod 规约中的 `terminationGracePeriodSeconds` 未设为 0，
`kubelet` 开始在容器内运行该回调逻辑。默认的 `terminationGracePeriodSeconds`
设置为 30 秒.
如果 `preStop` 回调在体面期结束后仍在运行，kubelet 将请求短暂的、一次性的体面期延长 2 秒。
说明：
如果 preStop 回调所需要的时间长于默认的体面终止限期，你必须修改
terminationGracePeriodSeconds 属性值来使其正常工作。
2. `kubelet` 接下来触发容器运行时发送 TERM 信号给每个容器中的进程 1。
如果 Pod 中定义了Sidecar 容器，
则存在[特殊排序](#termination-with-sidecars)。否则，Pod 中的容器会在不同的时间和任意的顺序接收
TERM 信号。如果关闭顺序很重要，考虑使用 `preStop` 钩子进行同步（或者切换为使用 Sidecar 容器）。
3. 在 `kubelet` 启动 Pod 的体面关闭逻辑的同时，控制平面会评估是否将关闭的
Pod 从对应的 EndpointSlice 对象中移除，过滤条件是 Pod
被对应的服务以某
选择算符选定。
ReplicaSet
和其他工作负载资源不再将关闭进程中的 Pod 视为合法的、能够提供服务的副本。
关闭动作很慢的 Pod 不应继续处理常规服务请求，而应开始终止并完成对打开的连接的处理。
一些应用程序不仅需要完成对打开的连接的处理，还需要更进一步的体面终止逻辑 -
比如：排空和完成会话。
任何正在终止的 Pod 所对应的端点都不会立即从 EndpointSlice
中被删除，EndpointSlice API 会公开一个状态来指示其处于
[终止状态](/zh-cn/docs/concepts/services-networking/endpoint-slices/#conditions)。
正在终止的端点始终将其 `ready` 状态设置为 `false`（为了向后兼容 1.26 之前的版本），
因此负载均衡器不会将其用于常规流量。
如果需要排空正被终止的 Pod 上的流量，可以将 `serving` 状况作为实际的就绪状态。你可以在教程
[探索 Pod 及其端点的终止行为](/zh-cn/docs/tutorials/services/pods-and-endpoint-termination-flow/)
中找到有关如何实现连接排空的更多详细信息。
4. kubelet 确保 Pod 被关闭和终止
1. 超出终止宽限期限时，如果 Pod 中仍有容器在运行，kubelet 会触发强制关闭过程。
容器运行时会向 Pod 中所有容器内仍在运行的进程发送 `SIGKILL` 信号。
`kubelet` 也会清理隐藏的 `pause` 容器，如果容器运行时使用了这种容器的话。
1. `kubelet` 将 Pod 转换到终止阶段（`Failed` 或 `Succeeded`，具体取决于其容器的结束状态）。
1. kubelet 通过将宽限期设置为 0（立即删除），触发从 API 服务器强制移除 Pod 对象的操作。
1. API 服务器删除 Pod 的 API 对象，从任何客户端都无法再看到该对象。
### 强制终止 Pod {#pod-termination-forced}
注意：
对于某些工作负载及其 Pod 而言，强制删除很可能会带来某种破坏。
注意：
马上删除时不等待确认正在运行的资源已被终止。这些资源可能会无限期地继续在集群上运行。
特性状态：
Kubernetes v1.35 [deprecated]（默认禁用）
当 kubelet 启动时，它会检查是否已经存在一个绑定了 Pod 的 Node。
如果该 Node 的 [`Ready` 状况](/zh-cn/docs/reference/node/node-status/#condition)保持不变，
也就是说该状况没有从 true 变为 false，Kubernetes 就会将其检测为一次 **kubelet 重启**。
（也可能通过其他方式重启 kubelet，例如为修复某个节点缺陷而重启；在这些情况下，
Kubernetes 会选择更安全的处理方式，例如先停止再启动 kubelet。）
当 kubelet 重启时，容器状态将基于特性门控的设置以不同方式进行管理：
* 默认情况下，kubelet 在重启后不更改容器状态。
之前设置为 `ready: true` 状态的容器仍然保持就绪。
如果你停止 kubelet 的时间足够长，
导致其连续多次[节点心跳](/zh-cn/docs/concepts/architecture/leases/#node-heart-beats)检查失败，
并且在重启 kubelet 之前又等待了一段时间，Kubernetes 可能会开始从该节点驱逐 Pod。
但是，即使开始发生 Pod 驱逐，Kubernetes 也不会将这些 Pod 中的单个容器标记为 `ready: false`。
Pod 级别的驱逐是在控制平面因心跳失败而将节点标记为 `node.kubernetes.io/not-ready` 之后发生的。
* 在 Kubernetes 1.36 中，你可以选择启用一种**传统的行为**：
在 kubelet 重启后，总是将容器的 `ready` 状态修改为 false。
这种传统行为在很长一段时间内都是默认设置的，但给 Kubernetes 用户带来了一些问题，
尤其是在大规模部署场景中。虽然此特性门控允许暂时回退到这种传统行为，
但 Kubernetes 项目建议如果你遇到相关问题，应提交 Bug 报告。
`ChangeContainerStatusOnKubeletRestart`
[特性门控](/docs/reference/command-line-tools-reference/feature-gates/#ChangeContainerStatusOnKubeletRestart)
将在未来被移除。
## 接下来
* 动手实践[为容器生命周期时间关联处理程序](/zh-cn/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)。
* 动手实践[配置存活态、就绪态和启动探针](/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)。
* 进一步了解[容器生命周期回调](/zh-cn/docs/concepts/containers/container-lifecycle-hooks/)。
* 进一步了解 [Sidecar 容器](/zh-cn/docs/concepts/workloads/pods/sidecar-containers/)。
* 关于 API 中定义的有关 Pod 和容器状态的详细规范信息，
可参阅 API 参考文档中 Pod 的 [`status`](/zh-cn/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodStatus) 字段。
