From 482f66f1aac2a4f856ebcad3650a2cb34b4ce4ec Mon Sep 17 00:00:00 2001
From: Michael <cloudyonspring@126.com>
Date: Thu, 6 Jul 2023 08:03:44 +0800
Subject: [PATCH] [zh] sync /workloads/pods/pod-lifecycle.md

---
 .../concepts/workloads/pods/pod-lifecycle.md  | 208 +++++++++---------
 1 file changed, 109 insertions(+), 99 deletions(-)

diff --git a/content/zh-cn/docs/concepts/workloads/pods/pod-lifecycle.md b/content/zh-cn/docs/concepts/workloads/pods/pod-lifecycle.md
index aa5cd93a1954d..9dad397d17620 100644
--- a/content/zh-cn/docs/concepts/workloads/pods/pod-lifecycle.md
+++ b/content/zh-cn/docs/concepts/workloads/pods/pod-lifecycle.md
@@ -74,8 +74,8 @@ Pod 也被计划在给定超时期限结束后[删除](#pod-garbage-collection)
 
 <!--
 Pods do not, by themselves, self-heal. If a Pod is scheduled to a
-{{< glossary_tooltip text="node" term_id="node" >}} that then fails, the Pod is deleted; likewise, a Pod won't
-survive an eviction due to a lack of resources or Node maintenance. Kubernetes uses a
+{{< glossary_tooltip text="node" term_id="node" >}} that then fails, the Pod is deleted; likewise,
+a Pod won't survive an eviction due to a lack of resources or Node maintenance. Kubernetes uses a
 higher-level abstraction, called a
 {{< glossary_tooltip term_id="controller" text="controller" >}}, that handles the work of
 managing the relatively disposable Pod instances.
@@ -110,11 +110,11 @@ created anew.
 {{< figure src="/images/docs/pod.svg" title="Pod 结构图例" class="diagram-medium" >}}
 
 <!--
-*A multi-container Pod that contains a file puller and a
-web server that uses a persistent volume for shared storage between the containers.*
+A multi-container Pod that contains a file puller and a
+web server that uses a persistent volume for shared storage between the containers.
 -->
-*一个包含多个容器的 Pod 中包含一个用来拉取文件的程序和一个 Web 服务器，
-均使用持久卷作为容器间共享的存储。*
+一个包含多个容器的 Pod 中包含一个用来拉取文件的程序和一个 Web 服务器，
+均使用持久卷作为容器间共享的存储。
 
 <!--
 ## Pod phase
@@ -178,9 +178,9 @@ Pod 被赋予一个可以体面终止的期限，默认为 30 秒。
 {{< /note >}}
 
 <!--
-Since Kubernetes 1.27, the kubelet transitions deleted pods, except for
-[static pods](/docs/tasks/configure-pod-container/static-pod/) and
-[force-deleted pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination-forced)
+Since Kubernetes 1.27, the kubelet transitions deleted Pods, except for
+[static Pods](/docs/tasks/configure-pod-container/static-pod/) and
+[force-deleted Pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination-forced)
 without a finalizer, to a terminal phase (`Failed` or `Succeeded` depending on
 the exit statuses of the pod containers) before their deletion from the API server.
 -->
@@ -412,7 +412,8 @@ status:
 ```
 
 <!--
-The Pod conditions you add must have names that meet the Kubernetes [label key format](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set).
+The Pod conditions you add must have names that meet the Kubernetes
+[label key format](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set).
 -->
 你所添加的 Pod 状况名称必须满足 Kubernetes
 [标签键名格式](/zh-cn/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)。
@@ -421,7 +422,7 @@ The Pod conditions you add must have names that meet the Kubernetes [label key f
 ### Status for Pod readiness {#pod-readiness-status}
 
 The `kubectl patch` command does not support patching object status.
-To set these `status.conditions` for the pod, applications and
+To set these `status.conditions` for the Pod, applications and
 {{< glossary_tooltip term_id="operator-pattern" text="operators">}} should use
 the `PATCH` action.
 You can use a [Kubernetes client library](/docs/reference/using-api/client-libraries/) to
@@ -465,15 +466,15 @@ When a Pod's containers are Ready but at least one custom condition is missing o
 After a Pod gets scheduled on a node, it needs to be admitted by the Kubelet and
 have any volumes mounted. Once these phases are complete, the Kubelet works with
 a container runtime (using {{< glossary_tooltip term_id="cri" >}}) to set up a
-runtime sandbox and configure networking for the Pod. If the
-`PodHasNetworkCondition` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled,
-Kubelet reports whether a pod has reached this initialization milestone through
+runtime sandbox and configure networking for the Pod. If the `PodHasNetworkCondition`
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled,
+Kubelet reports whether a Pod has reached this initialization milestone through
 the `PodHasNetwork` condition in the `status.conditions` field of a Pod.
 -->
 在 Pod 被调度到某节点后，它需要被 Kubelet 接受并且挂载所需的卷。
 一旦这些阶段完成，Kubelet 将与容器运行时（使用{{< glossary_tooltip term_id="cri" >}}）
-一起为 Pod 生成运行时沙箱并配置网络。
-如果启用了 `PodHasNetworkCondition` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)，
+一起为 Pod 生成运行时沙箱并配置网络。如果启用了
+`PodHasNetworkCondition` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)，
 kubelet 会通过 Pod 的 `status.conditions` 字段中的 `PodHasNetwork` 状况来报告
 Pod 是否达到了初始化里程碑。
 
@@ -484,13 +485,15 @@ the following scenarios:
 -->
 当 kubelet 检测到 Pod 不具备配置了网络的运行时沙箱时，`PodHasNetwork` 状况将被设置为 `False`。
 以下场景中将会发生这种状况：
+
 <!--
-* Early in the lifecycle of the Pod, when the kubelet has not yet begun to set up a sandbox for the Pod using the container runtime.
-* Later in the lifecycle of the Pod, when the Pod sandbox has been destroyed due
-  to either:
-  * the node rebooting, without the Pod getting evicted
-  * for container runtimes that use virtual machines for isolation, the Pod
-    sandbox virtual machine rebooting, which then requires creating a new sandbox and fresh container network configuration.
+- Early in the lifecycle of the Pod, when the kubelet has not yet begun to set up a sandbox for
+  the Pod using the container runtime.
+- Later in the lifecycle of the Pod, when the Pod sandbox has been destroyed due to either:
+  - the node rebooting, without the Pod getting evicted
+  - for container runtimes that use virtual machines for isolation, the Pod
+    sandbox virtual machine rebooting, which then requires creating a new sandbox and
+    fresh container network configuration.
 -->
 * 在 Pod 生命周期的早期阶段，kubelet 还没有开始使用容器运行时为 Pod 设置沙箱时。
 * 在 Pod 生命周期的末期阶段，Pod 的沙箱由于以下原因被销毁时：
@@ -529,23 +532,21 @@ condition to `True` before sandbox creation and network configuration starts.
 {{< feature-state for_k8s_version="v1.26" state="alpha" >}}
 
 <!--
-See [Pod Scheduling Readiness](/docs/concepts/scheduling-eviction/pod-scheduling-readiness/) for more information.
+See [Pod Scheduling Readiness](/docs/concepts/scheduling-eviction/pod-scheduling-readiness/)
+for more information.
 -->
 有关详细信息，请参阅 [Pod 调度就绪态](/zh-cn/docs/concepts/scheduling-eviction/pod-scheduling-readiness/)。
 
 <!--
 ## Container probes
 
-A _probe_ is a diagnostic
-performed periodically by the
-[kubelet](/docs/reference/command-line-tools-reference/kubelet/)
-on a container. To perform a diagnostic,
-the kubelet either executes code within the container, or makes
-a network request.
+A _probe_ is a diagnostic performed periodically by the [kubelet](/docs/reference/command-line-tools-reference/kubelet/)
+on a container. To perform a diagnostic, the kubelet either executes code within the container,
+or makes a network request.
 -->
 ## 容器探针    {#container-probes}
 
-probe 是由 [kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/) 对容器执行的定期诊断。
+**probe** 是由 [kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/) 对容器执行的定期诊断。
 要执行诊断，kubelet 既可以在容器内执行代码，也可以发出一个网络请求。
 
 <!--
@@ -701,8 +702,6 @@ see [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod
 -->
 #### 何时该使用存活态探针?    {#when-should-you-use-a-liveness-probe}
 
-{{< feature-state for_k8s_version="v1.0" state="stable" >}}
-
 <!--
 If the process in your container is able to crash on its own whenever it
 encounters an issue or becomes unhealthy, you do not necessarily need a liveness
@@ -723,8 +722,6 @@ specify a liveness probe, and specify a `restartPolicy` of Always or OnFailure.
 -->
 #### 何时该使用就绪态探针?      {#when-should-you-use-a-readiness-probe}
 
-{{< feature-state for_k8s_version="v1.0" state="stable" >}}
-
 <!--
 If you'd like to start sending traffic to a Pod only when a probe succeeds,
 specify a readiness probe. In this case, the readiness probe might be the same
@@ -783,8 +780,6 @@ to stop.
 -->
 #### 何时该使用启动探针？   {#when-should-you-use-a-startup-probe}
 
-{{< feature-state for_k8s_version="v1.20" state="stable" >}}
-
 <!--
 Startup probes are useful for Pods that have containers that take a long time to
 come into service. Rather than set a long liveness interval, you can configure
@@ -839,11 +834,10 @@ Pod。
 Typically, the container runtime sends a TERM signal to the main process in each
 container. Many container runtimes respect the `STOPSIGNAL` value defined in the container
 image and send this instead of TERM.
-Once the grace period has expired, the KILL signal is sent to any remaining
-processes, and the Pod is then deleted from the
-{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}. If the kubelet or the
-container runtime's management service is restarted while waiting for processes to terminate, the
-cluster retries from the start including the full original grace period.
+Once the grace period has expired, the KILL signal is sent to any remaining processes, and the Pod
+is then deleted from the {{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}.
+If the kubelet or the container runtime's management service is restarted while waiting for
+processes to terminate, the cluster retries from the start including the full original grace period.
 -->
 通常情况下，容器运行时会发送一个 TERM 信号到每个容器中的主进程。
 很多容器运行时都能够注意到容器镜像中 `STOPSIGNAL` 的值，并发送该信号而不是 TERM。
@@ -857,10 +851,10 @@ An example flow:
 
 1. You use the `kubectl` tool to manually delete a specific Pod, with the default grace period
    (30 seconds).
+
 1. The Pod in the API server is updated with the time beyond which the Pod is considered "dead"
    along with the grace period.
-   If you use `kubectl describe` to check on the Pod you're deleting, that Pod shows up as
-   "Terminating".
+   If you use `kubectl describe` to check the Pod you're deleting, that Pod shows up as "Terminating".
    On the node where the Pod is running: as soon as the kubelet sees that a Pod has been marked
    as terminating (a graceful shutdown duration has been set), the kubelet begins the local Pod
    shutdown process.
@@ -878,10 +872,12 @@ An example flow:
 
    <!--
    1. If one of the Pod's containers has defined a `preStop`
-      [hook](/docs/concepts/containers/container-lifecycle-hooks), the kubelet
-      runs that hook inside of the container. If the `preStop` hook is still running after the
-      grace period expires, the kubelet requests a small, one-off grace period extension of 2
-      seconds.
+      [hook](/docs/concepts/containers/container-lifecycle-hooks) and the `terminationGracePeriodSeconds`
+      in the Pod spec is not set to 0, the kubelet runs that hook inside of the container.
+      The default `terminationGracePeriodSeconds` setting is 30 seconds.
+
+      If the `preStop` hook is still running after the grace period expires, the kubelet requests
+      a small, one-off grace period extension of 2 seconds.
    -->
 
    1. 如果 Pod 中的容器之一定义了 `preStop`
@@ -889,6 +885,8 @@ An example flow:
       `kubelet` 开始在容器内运行该回调逻辑。如果超出体面终止限期时，
       `preStop` 回调逻辑仍在运行，`kubelet` 会请求给予该 Pod 的宽限期一次性增加 2 秒钟。
 
+      如果 `preStop` 回调在体面期结束后仍在运行，kubelet 将请求短暂的、一次性的体面期延长 2 秒。
+
       {{< note >}}
       <!--
       If the `preStop` hook needs longer to complete than the default grace period allows,
@@ -915,24 +913,17 @@ An example flow:
       {{< /note >}}
 
 <!--
-1. At the same time as the kubelet is starting graceful shutdown of the Pod, the control plane evaluates whether
-   to remove that shutting-down Pod from EndpointSlice (and Endpoints) objects, where those objects represent
-   a {{< glossary_tooltip term_id="service" text="Service" >}} with a configured
-   {{< glossary_tooltip text="selector" term_id="selector" >}}.
+1. At the same time as the kubelet is starting graceful shutdown of the Pod, the control plane
+   evaluates whether to remove that shutting-down Pod from EndpointSlice (and Endpoints) objects,
+   where those objects represent a {{< glossary_tooltip term_id="service" text="Service" >}}
+   with a configured {{< glossary_tooltip text="selector" term_id="selector" >}}.
    {{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}} and other workload resources
-   no longer treat the shutting-down Pod as a valid, in-service replica. Pods that shut down slowly
-   should not continue to serve regular traffic and should start terminating and finish processing open connections.
-   Some applications need to go beyond finishing open connections and need more graceful termination -
-   for example: session draining and completion. Any endpoints that represent the terminating pods
-   are not immediately removed from EndpointSlices,
-   and a status indicating [terminating state](/docs/concepts/services-networking/endpoint-slices/#conditions)
-   is exposed from the EndpointSlice API (and the legacy Endpoints API). Terminating
-   endpoints always have their `ready` status
-   as `false` (for backward compatibility with versions before 1.26),
-   so load balancers will not use it for regular traffic.
-   If traffic draining on terminating pod is needed, the actual readiness can be checked as a condition `serving`.
-   You can find more details on how to implement connections draining
-   in the tutorial [Pods And Endpoints Termination Flow](/docs/tutorials/services/pods-and-endpoint-termination-flow/)
+   no longer treat the shutting-down Pod as a valid, in-service replica.
+
+   Pods that shut down slowly should not continue to serve regular traffic and should start
+   terminating and finish processing open connections.  Some applications need to go beyond
+   finishing open connections and need more graceful termination, for example, session draining
+   and completion.
 -->
 3. 在 `kubelet` 启动 Pod 的体面关闭逻辑的同时，控制平面会评估是否将关闭的
    Pod 从对应的 EndpointSlice（和端点）对象中移除，过滤条件是 Pod
@@ -940,38 +931,51 @@ An example flow:
    {{< glossary_tooltip text="选择算符" term_id="selector" >}}选定。
    {{< glossary_tooltip text="ReplicaSet" term_id="replica-set" >}}
    和其他工作负载资源不再将关闭进程中的 Pod 视为合法的、能够提供服务的副本。
+
    关闭动作很慢的 Pod 不应继续处理常规服务请求，而应开始终止并完成对打开的连接的处理。
    一些应用程序不仅需要完成对打开的连接的处理，还需要更进一步的体面终止逻辑 -
-   比如：排空和完成会话。任何正在终止的 Pod 所对应的端点都不会立即从 EndpointSlice
+   比如：排空和完成会话。
+
+   <!--
+   Any endpoints that represent the terminating Pods are not immediately removed from
+   EndpointSlices, and a status indicating [terminating state](/docs/concepts/services-networking/endpoint-slices/#conditions)
+   is exposed from the EndpointSlice API (and the legacy Endpoints API).
+   Terminating endpoints always have their `ready` status as `false` (for backward compatibility
+   with versions before 1.26), so load balancers will not use it for regular traffic.
+
+   If traffic draining on terminating Pod is needed, the actual readiness can be checked as a
+   condition `serving`.  You can find more details on how to implement connections draining in the
+   tutorial [Pods And Endpoints Termination Flow](/docs/tutorials/services/pods-and-endpoint-termination-flow/)
+   -->
+   任何正在终止的 Pod 所对应的端点都不会立即从 EndpointSlice
    中被删除，EndpointSlice API（以及传统的 Endpoints API）会公开一个状态来指示其处于
    [终止状态](/zh-cn/docs/concepts/services-networking/endpoint-slices/#conditions)。
    正在终止的端点始终将其 `ready` 状态设置为 `false`（为了向后兼容 1.26 之前的版本），
    因此负载均衡器不会将其用于常规流量。
-   如果需要排空正被终止的 Pod 上的流量，可以将 `serving` 状况作为实际的就绪状态。
-   你可以在教程
+
+   如果需要排空正被终止的 Pod 上的流量，可以将 `serving` 状况作为实际的就绪状态。你可以在教程
    [探索 Pod 及其端点的终止行为](/zh-cn/docs/tutorials/services/pods-and-endpoint-termination-flow/)
    中找到有关如何实现连接排空的更多详细信息。
 
-   {{<note>}}
-   <!--
-   If you don't have the `EndpointSliceTerminatingCondition` feature gate enabled
-   in your cluster (the gate is on by default from Kubernetes 1.22, and locked to default in 1.26), then the Kubernetes control
-   plane removes a Pod from any relevant EndpointSlices as soon as the Pod's
-   termination grace period _begins_. The behavior above is described when the
-   feature gate `EndpointSliceTerminatingCondition` is enabled.
-   -->
-   如果你的集群中没有启用 EndpointSliceTerminatingCondition 特性门控
-   （该门控从 Kubernetes 1.22 开始默认开启，在 1.26 中锁定为默认），
-   那么一旦 Pod 的终止宽限期开始，Kubernetes 控制平面就会从所有的相关 EndpointSlices 中移除 Pod。
-   上述行为是在 EndpointSliceTerminatingCondition 特性门控被启用时描述的。
-   {{</note>}}
-
+{{<note>}}
+<!--
+If you don't have the `EndpointSliceTerminatingCondition` feature gate enabled
+in your cluster (the gate is on by default from Kubernetes 1.22, and locked to default in 1.26),
+then the Kubernetes control plane removes a Pod from any relevant EndpointSlices as soon as the Pod's
+termination grace period _begins_. The behavior above is described when the
+feature gate `EndpointSliceTerminatingCondition` is enabled.
+-->
+如果你的集群中没有启用 EndpointSliceTerminatingCondition 特性门控
+（该门控从 Kubernetes 1.22 开始默认开启，在 1.26 中锁定为默认），
+那么一旦 Pod 的终止宽限期开始，Kubernetes 控制平面就会从所有的相关 EndpointSlices 中移除 Pod。
+上述行为是在 EndpointSliceTerminatingCondition 特性门控被启用时描述的。
+{{</note>}}
 
 <!--
 1. When the grace period expires, the kubelet triggers forcible shutdown. The container runtime sends
    `SIGKILL` to any processes still running in any container in the Pod.
    The kubelet also cleans up a hidden `pause` container if that container runtime uses one.
-1. The kubelet transitions the pod into a terminal phase (`Failed` or `Succeeded` depending on
+1. The kubelet transitions the Pod into a terminal phase (`Failed` or `Succeeded` depending on
    the end state of its containers). This step is guaranteed since version 1.27.
 1. The kubelet triggers forcible removal of Pod object from the API server, by setting grace period
    to 0 (immediate deletion).
@@ -1012,7 +1016,7 @@ own value.
 
 <!--
 Setting the grace period to `0` forcibly and immediately deletes the Pod from the API
-server. If the pod was still running on a node, that forcible deletion triggers the kubelet to
+server. If the Pod was still running on a node, that forcible deletion triggers the kubelet to
 begin immediate cleanup.
 -->
 将宽限期限强制设置为 `0` 意味着立即从 API 服务器删除 Pod。
@@ -1020,7 +1024,8 @@ begin immediate cleanup.
 
 {{< note >}}
 <!--
-You must specify an additional flag `--force` along with `--grace-period=0` in order to perform force deletions.
+You must specify an additional flag `--force` along with `--grace-period=0`
+in order to perform force deletions.
 -->
 你必须在设置 `--grace-period=0` 的同时额外设置 `--force` 参数才能发起强制删除请求。
 {{< /note >}}
@@ -1039,7 +1044,8 @@ API 服务器直接删除 Pod 对象，这样新的与之同名的 Pod 即可以
 
 {{< caution >}}
 <!--
-Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely.
+Immediate deletion does not wait for confirmation that the running resource has been terminated.
+The resource may continue to run on the cluster indefinitely.
 -->
 马上删除时不等待确认正在运行的资源已被终止。这些资源可能会无限期地继续在集群上运行。
 {{< /caution >}}
@@ -1059,9 +1065,9 @@ For failed Pods, the API objects remain in the cluster's API until a human or
 {{< glossary_tooltip term_id="controller" text="controller" >}} process
 explicitly removes them.
 
-The Pod garbage collector (PodGC), which is a controller in the control plane, cleans up terminated Pods (with a phase of `Succeeded` or
-`Failed`), when the number of Pods exceeds the configured threshold
-(determined by `terminated-pod-gc-threshold` in the kube-controller-manager).
+The Pod garbage collector (PodGC), which is a controller in the control plane, cleans up
+terminated Pods (with a phase of `Succeeded` or `Failed`), when the number of Pods exceeds the
+configured threshold (determined by `terminated-pod-gc-threshold` in the kube-controller-manager).
 This avoids a resource leak as Pods are created and terminated over time.
 -->
 ### Pod 的垃圾收集    {#pod-garbage-collection}
@@ -1076,17 +1082,21 @@ Pod（阶段值为 `Succeeded` 或 `Failed`）。
 
 <!--
 Additionally, PodGC cleans up any Pods which satisfy any of the following conditions:
-1. are orphan pods - bound to a node which no longer exists,
-2. are unscheduled terminating pods,
-3. are terminating pods, bound to a non-ready node tainted with [`node.kubernetes.io/out-of-service`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-out-of-service), when the `NodeOutOfServiceVolumeDetach` feature gate is enabled.
+
+1. are orphan Pods - bound to a node which no longer exists,
+1. are unscheduled terminating Pods,
+1. are terminating Pods, bound to a non-ready node tainted with
+   [`node.kubernetes.io/out-of-service`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-out-of-service),
+   when the `NodeOutOfServiceVolumeDetach` feature gate is enabled.
 
 When the `PodDisruptionConditions` feature gate is enabled, along with
-cleaning up the pods, PodGC will also mark them as failed if they are in a non-terminal
-phase. Also, PodGC adds a pod disruption condition when cleaning up an orphan
-pod (see also:
-[Pod disruption conditions](/docs/concepts/workloads/pods/disruptions#pod-disruption-conditions)).
+cleaning up the Pods, PodGC will also mark them as failed if they are in a non-terminal
+phase. Also, PodGC adds a Pod disruption condition when cleaning up an orphan Pod.
+See [Pod disruption conditions](/docs/concepts/workloads/pods/disruptions#pod-disruption-conditions)
+for more details.
 -->
 此外，PodGC 会清理满足以下任一条件的所有 Pod：
+
 1. 孤儿 Pod - 绑定到不再存在的节点，
 2. 计划外终止的 Pod
 3. 终止过程中的 Pod，当启用 `NodeOutOfServiceVolumeDetach` 特性门控时，
@@ -1095,8 +1105,8 @@ pod (see also:
 
 若启用 `PodDisruptionConditions` 特性门控，在清理 Pod 的同时，
 如果它们处于非终止状态阶段，PodGC 也会将它们标记为失败。
-此外，PodGC 在清理孤儿 Pod 时会添加 Pod 干扰状况（另请参阅：
-[Pod 干扰状况](/zh-cn/docs/concepts/workloads/pods/disruptions#pod-disruption-conditions)）。
+此外，PodGC 在清理孤儿 Pod 时会添加 Pod 干扰状况。参阅
+[Pod 干扰状况](/zh-cn/docs/concepts/workloads/pods/disruptions#pod-disruption-conditions) 了解更多详情。
 
 ## {{% heading "whatsnext" %}}
 
@@ -1111,10 +1121,10 @@ pod (see also:
 
 * For detailed information about Pod and container status in the API, see
   the API reference documentation covering
-  [`.status`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodStatus) for Pod.
+  [`status`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodStatus) for Pod.
 -->
 * 动手实践[为容器生命周期时间关联处理程序](/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/)。
 * 关于 API 中定义的有关 Pod 和容器状态的详细规范信息，
-  可参阅 API 参考文档中 Pod 的 [`.status`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodStatus) 字段。
+  可参阅 API 参考文档中 Pod 的 [`status`](/zh-cn/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodStatus) 字段。