Merge pull request #34564 from Sea-n/zh-fix-conecpts-links

[zh] Fix some 404 links in concepts

content/zh-cn/docs/concepts/overview/working-with-objects/finalizers.md

@@ -87,7 +87,7 @@ Kubernetes 清除 `pv-protection` Finalizer，控制器就会删除该卷。
 ## Owner references, labels, and finalizers {#owners-labels-finalizers}
 
 Like {{<glossary_tooltip text="labels" term_id="label">}},
-[owner references](/concepts/overview/working-with-objects/owners-dependents/)
+[owner references](/docs/concepts/overview/working-with-objects/owners-dependents/)
 describe the relationships between objects in Kubernetes, but are used for a
 different purpose. When a
 {{<glossary_tooltip text="controller" term_id="controller">}} manages objects
@@ -99,7 +99,7 @@ any Pods in the cluster with the same label.
 ## 属主引用、标签和 Finalizers {#owners-labels-finalizers}
 
 与{{<glossary_tooltip text="标签" term_id="label">}}类似，
-[属主引用](/zh-cn/concepts/overview/working-with-objects/owners-dependents/)
+[属主引用](/zh-cn/docs/concepts/overview/working-with-objects/owners-dependents/)
 描述了 Kubernetes 中对象之间的关系，但它们作用不同。
 当一个{{<glossary_tooltip text="控制器" term_id="controller">}}
 管理类似于 Pod 的对象时，它使用标签来跟踪相关对象组的变化。
@@ -154,4 +154,3 @@ Finalizers 通常因为特殊原因被添加到资源上，所以强行删除它
   on the Kubernetes blog.
 -->
 * 在 Kubernetes 博客上阅读[使用 Finalizers 控制删除](/blog/2021/05/14/using-finalizers-to-control-deletion/)。
-

content/zh-cn/docs/concepts/security/pod-security-policy.md

@@ -58,7 +58,7 @@ Pod 安全策略允许管理员控制如下方面：
 
 <!--
 | Control Aspect                                      | Field Names                                 |
-| ----------------------------------------------------| ----------------------------------------- |
+| ----------------------------------------------------| ------------------------------------------- |
 | Running of privileged containers                    | [`privileged`](#privileged)                                |
 | Usage of host namespaces                            | [`hostPID`, `hostIPC`](#host-namespaces)    |
 | Usage of host networking and ports                  | [`hostNetwork`, `hostPorts`](#host-namespaces) |
@@ -458,11 +458,11 @@ alias kubectl-user='kubectl --as=system:serviceaccount:psp-example:fake-user -n
 ### Create a policy and a pod
 
 Define the example PodSecurityPolicy object in a file. This is a policy that
-simply prevents the creation of privileged pods.
+prevents the creation of privileged pods.
 The name of a PodSecurityPolicy object must be a valid
 [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
 -->
-### 创建一个策略和一个 Pod
+### 创建一个策略和一个 Pod   {#create-a-policy-and-a-pod}
 
 在一个文件中定义一个示例的 PodSecurityPolicy 对象。
 这里的策略只是用来禁止创建有特权要求的 Pods。
@@ -588,7 +588,7 @@ spec:
 EOF
 ```
 <!--
-The output is similar to this:
+The output is similar to this
 -->
 输出类似于：
 
@@ -791,7 +791,8 @@ several security mechanisms.
 {{< codenew file="policy/restricted-psp.yaml" >}}
 
 <!--
-See [Pod Security Standards](/docs/concepts/security/pod-security-standards/#policy-instantiation) for more examples.
+See [Pod Security Standards](/docs/concepts/security/pod-security-standards/#policy-instantiation)
+for more examples.
 -->
 更多的示例可参考
 [Pod 安全标准](/zh-cn/docs/concepts/security/pod-security-standards/#policy-instantiation)。
@@ -897,10 +898,10 @@ PodSecurityPolicy 并不限制可以被 `PersistentVolumeClaim` 所引用的
 **FSGroup** - Controls the supplemental group applied to some volumes.
 
 - *MustRunAs* - Requires at least one `range` to be specified. Uses the
-minimum value of the first range as the default. Validates against all ranges.
+  minimum value of the first range as the default. Validates against all ranges.
 - *MayRunAs* - Requires at least one `range` to be specified. Allows
-`FSGroups` to be left unset without providing a default. Validates against
+  `FSGroups` to be left unset without providing a default. Validates against
-all ranges if `FSGroups` is set.
+  all ranges if `FSGroups` is set.
 - *RunAsAny* - No default provided. Allows any `fsGroup` ID to be specified.
 -->
 **FSGroup** - 控制应用到某些卷上的附加用户组。
@@ -1054,7 +1055,7 @@ spec:
 <!--
 **RunAsGroup** - Controls which primary group ID the containers are run with.
 
-- *MustRunAs* - Requires at least one `range` to be specified. Uses the 
+- *MustRunAs* - Requires at least one `range` to be specified. Uses the
   minimum value of the first range as the default. Validates against all ranges.
 - *MayRunAs* - Does not require that RunAsGroup be specified. However, when RunAsGroup
   is specified, they have to fall in the defined range.
@@ -1101,7 +1102,7 @@ required to effectively enforce `MustRunAsNonRoot`.
 -->
 ### 特权提升   {#privilege-escalation}
 
-这一组选项控制容器的`allowPrivilegeEscalation` 属性。该属性直接决定是否为容器进程设置
+这一组选项控制容器的 `allowPrivilegeEscalation` 属性。该属性直接决定是否为容器进程设置
 [`no_new_privs`](https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt)
 参数。此参数会禁止 `setuid` 属性的可执行文件更改有效用户 ID（EUID），
 并且禁止启用额外权能的文件。例如，`no_new_privs` 会禁止使用 `ping` 工具。
@@ -1140,7 +1141,7 @@ the PodSecurityPolicy. For more details on Linux capabilities, see
 [capabilities(7)](http://man7.org/linux/man-pages/man7/capabilities.7.html).
 
 The following fields take a list of capabilities, specified as the capability
-name in ALL_CAPS without the `CAP\_` prefix.
+name in ALL_CAPS without the `CAP_` prefix.
 -->
 ### 权能字    {#capabilities}
 
@@ -1176,7 +1177,7 @@ added. Capabilities listed in `RequiredDropCapabilities` must not be included in
 <!--
 **DefaultAddCapabilities** - The capabilities which are added to containers by
 default, in addition to the runtime defaults. See the
-documentation for your container runtime for information on working with Linux capabilities. 
+documentation for your container runtime for information on working with Linux capabilities.
 -->
 **DefaultAddCapabilities** - 默认添加到容器的权能字集合。
 这一集合是作为容器运行时所设值的补充。
@@ -1228,14 +1229,14 @@ denoted as the string `Unmasked`.
 <!--
 ### AppArmor
 
-Controlled via annotations on the PodSecurityPolicy. Refer to the [AppArmor
+Controlled via annotations on the PodSecurityPolicy. Refer to the
-documentation](/docs/tutorials/policy/apparmor/#podsecuritypolicy-annotations).
+[AppArmor documentation](/docs/tutorials/security/apparmor/#podsecuritypolicy-annotations).
 -->
 ### AppArmor
 
 通过 PodSecurityPolicy 上的注解来控制。
 详情请参阅
-[AppArmor 文档](/zh-cn/docs/tutorials/policy/apparmor/#podsecuritypolicy-annotations)。
+[AppArmor 文档](/zh-cn/docs/tutorials/security/apparmor/#podsecuritypolicy-annotations)。
 
 
 <!--
@@ -1270,7 +1271,7 @@ are:
   of Kubernetes 1.11. Use `runtime/default` instead.
 - `localhost/<path>` - Specify a profile as a file on the node located at
   `<seccomp_root>/<path>`, where `<seccomp_root>` is defined via the
-  `-seccomp-profile-root` flag on the Kubelet. If the `--seccomp-profile-root`
+  `--seccomp-profile-root` flag on the Kubelet. If the `--seccomp-profile-root`
   flag is not defined, the default path will be used, which is
   `<root-dir>/seccomp` where `<root-dir>` is specified by the `--root-dir` flag.
 
@@ -1341,20 +1342,21 @@ Refer to the [Sysctl documentation](/docs/tasks/administer-cluster/sysctl-cluste
 ## {{% heading "whatsnext" %}}
 
 <!--
-- See [PodSecurityPolicy Deprecation: Past, Present, and
+- See [PodSecurityPolicy Deprecation: Past, Present, and Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)
-  Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/) to learn about
+  to learn about the future of pod security policy.
-  the future of pod security policy.
 
-- See [Pod Security Standards](/docs/concepts/security/pod-security-standards/) for policy recommendations.
+- See [Pod Security Standards](/docs/concepts/security/pod-security-standards/)
+  for policy recommendations.
 
-- Refer to [Pod Security Policy Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) for the api details.
+- Refer to [PodSecurityPolicy reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy)
+  for the API details.
 -->
 - 参阅 [PodSecurityPolicy Deprecation: Past, Present, and
   Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)，
   了解 Pod 安全策略的未来。
 
-- 参阅[Pod 安全标准](/zh-cn/docs/concepts/security/pod-security-standards/)，
+- 参阅 [Pod 安全标准](/zh-cn/docs/concepts/security/pod-security-standards/)，
   了解策略建议。
-- 阅读 [Pod 安全策略参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy)，
+- 阅读 [PodSecurityPolicy 参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy)，
   了解 API 细节。
 

content/zh-cn/docs/concepts/windows/intro.md

@@ -468,7 +468,7 @@ The following list documents differences between how Pod specifications work bet
   supported on Windows.
 -->
 * `terminationGracePeriodSeconds` - 这在 Windows 上的 Docker 中没有完全实现，
-  请参考[GitHub issue](https://github.com/moby/moby/issues/25982)。
+  请参考 [GitHub issue](https://github.com/moby/moby/issues/25982)。
   目前的行为是通过 CTRL_SHUTDOWN_EVENT 发送 ENTRYPOINT 进程，然后 Windows 默认等待 5 秒，
   最后使用正常的 Windows 关机行为终止所有进程。
   5 秒默认值实际上位于[容器内](https://github.com/moby/moby/issues/25982#issuecomment-426441183)的 Windows 注册表中，
@@ -637,7 +637,7 @@ Windows Server SAC release
 <!--
 The Kubernetes [version-skew policy](/docs/setup/release/version-skew-policy/) also applies.
 -->
-也适用 Kubernetes [版本偏差策略](/zh-cn/docs/setup/release/version-skew-policy/)。
+也适用 Kubernetes [版本偏差策略](/zh-cn/releases/version-skew-policy/)。
 
 <!--
 ## Getting help and troubleshooting {#troubleshooting}

content/zh-cn/docs/concepts/workloads/controllers/replicationcontroller.md

@@ -7,7 +7,7 @@ feature:
     重新启动失败的容器，在节点死亡时替换并重新调度容器，杀死不响应用户定义的健康检查的容器，并且在它们准备好服务之前不会将它们公布给客户端。
 content_type: concept
 weight: 90
----     
+---
 
 <!--
 reviewers:
@@ -242,8 +242,8 @@ different, and the `.metadata.labels` do not affect the behavior of the Replicat
 ### ReplicationController 上的标签
 
 ReplicationController 本身可以有标签 （`.metadata.labels`）。
-通常，你可以将这些设置为 `.spec.template.metadata.labels`； 
+通常，你可以将这些设置为 `.spec.template.metadata.labels`；
-如果没有指定 `.metadata.labels` 那么它默认为 `.spec.template.metadata.labels`。  
+如果没有指定 `.metadata.labels` 那么它默认为 `.spec.template.metadata.labels`。
 但是，Kubernetes 允许它们是不同的，`.metadata.labels` 不会影响 ReplicationController 的行为。
 
 <!--
@@ -256,7 +256,7 @@ deleted. This allows the ReplicationController to be replaced without affecting
 -->
 ### Pod 选择算符 {#pod-selector}
 
-`.spec.selector` 字段是一个[标签选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/#label-selectors)。 
+`.spec.selector` 字段是一个[标签选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/#label-selectors)。
 ReplicationController 管理标签与选择算符匹配的所有 Pod。
 它不区分它创建或删除的 Pod 和其他人或进程创建或删除的 Pod。
 这允许在不影响正在运行的 Pod 的情况下替换 ReplicationController。
@@ -299,7 +299,7 @@ If you do not specify `.spec.replicas`, then it defaults to 1.
 你可以通过设置 `.spec.replicas` 来指定应该同时运行多少个 Pod。
 在任何时候，处于运行状态的 Pod 个数都可能高于或者低于设定值。例如，副本个数刚刚被增加或减少时，或者一个 Pod 处于优雅终止过程中而其替代副本已经提前开始创建时。
 
-如果你没有指定 `.spec.replicas` ，那么它默认是 1。
+如果你没有指定 `.spec.replicas`，那么它默认是 1。
 
 <!--
 ## Working with ReplicationControllers
@@ -341,7 +341,7 @@ When using the REST API or [client library](/docs/reference/using-api/client-lib
 
 使用 kubectl，为 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 指定 `--cascade=orphan` 选项。
 
-当使用 REST API 或客户端库(/zh-cn/docs/reference/using-api/client-libraries)时，只需删除 ReplicationController 对象。
+当使用 REST API 或[客户端库](/zh-cn/docs/reference/using-api/client-libraries)时，只需删除 ReplicationController 对象。
 
 <!--
 Once the original is deleted, you can create a new ReplicationController to replace it.  As long
@@ -561,9 +561,9 @@ Unlike in the case where a user directly created pods, a ReplicationController r
 ### 裸 Pod
 
 与用户直接创建 Pod 的情况不同，ReplicationController 能够替换因某些原因
-被删除或被终止的 Pod ，例如在节点故障或中断节点维护的情况下，例如内核升级。
+被删除或被终止的 Pod，例如在节点故障或中断节点维护的情况下，例如内核升级。
 因此，我们建议你使用 ReplicationController，即使你的应用程序只需要一个 Pod。
-可以将其看作类似于进程管理器，它只管理跨多个节点的多个 Pod ，而不是单个节点上的单个进程。
+可以将其看作类似于进程管理器，它只管理跨多个节点的多个 Pod，而不是单个节点上的单个进程。
 ReplicationController 将本地容器重启委托给节点上的某个代理(例如，Kubelet 或 Docker)。
 
 <!--

content/zh-cn/docs/concepts/workloads/controllers/statefulset.md

@@ -27,7 +27,7 @@ StatefulSet 是用来管理有状态应用的工作负载 API 对象。
 StatefulSets are valuable for applications that require one or more of the
 following.
 -->
-## 使用 StatefulSets
+## 使用 StatefulSets   {#using-statefulsets}
 
 StatefulSets 对于需要满足以下一个或多个需求的应用程序很有价值：
 
@@ -164,7 +164,7 @@ The name of a StatefulSet object must be a valid
 * `volumeClaimTemplates` 将通过 PersistentVolumes 驱动提供的
   [PersistentVolumes](/zh-cn/docs/concepts/storage/persistent-volumes/) 来提供稳定的存储。
 
-StatefulSet 的命名需要遵循[DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)规范。
+StatefulSet 的命名需要遵循 [DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)规范。
 
 <!--
 ### Pod Selector
@@ -178,7 +178,7 @@ You must set the `.spec.selector` field of a StatefulSet to match the labels of
 `.spec.template.metadata.labels` 中设置的标签。
 未指定匹配的 Pod 选择器将在创建 StatefulSet 期间导致验证错误。
 
-<!-- 
+<!--
 ### Volume Claim Templates
 
 You can set the  `.spec.volumeClaimTemplates` which can provide stable storage using [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) provisioned by a PersistentVolume Provisioner.
@@ -194,7 +194,7 @@ You can set the  `.spec.volumeClaimTemplates` which can provide stable storage u
 
 {{< feature-state for_k8s_version="v1.23" state="beta" >}}
 
-<!-- 
+<!--
 `.spec.minReadySeconds` is an optional field that specifies the minimum number of seconds for which a newly
 created Pod should be ready without any of its containers crashing, for it to be considered available.
 Please note that this feature is beta and enabled by default. Please opt out by unsetting the StatefulSetMinReadySeconds flag, if you don't
@@ -332,9 +332,9 @@ This must be done manually.
 对于 StatefulSet 中定义的每个 VolumeClaimTemplate，每个 Pod 接收到一个 PersistentVolumeClaim。在上面的 nginx 示例中，每个 Pod 将会得到基于 StorageClass `my-storage-class` 提供的
 1 Gib 的 PersistentVolume。
 如果没有声明 StorageClass，就会使用默认的 StorageClass。
-当一个 Pod 被调度（重新调度）到节点上时，它的 `volumeMounts` 会挂载与其 
+当一个 Pod 被调度（重新调度）到节点上时，它的 `volumeMounts` 会挂载与其
 PersistentVolumeClaims 相关联的 PersistentVolume。
-请注意，当 Pod 或者 StatefulSet 被删除时，与 PersistentVolumeClaims 相关联的 
+请注意，当 Pod 或者 StatefulSet 被删除时，与 PersistentVolumeClaims 相关联的
 PersistentVolume 并不会被删除。要删除它必须通过手动方式来完成。
 
 <!--
@@ -417,7 +417,7 @@ StatefulSet 允许你放宽其排序保证，
 `OrderedReady` pod management is the default for StatefulSets. It implements the behavior
 described [above](#deployment-and-scaling-guarantees).
 -->
-#### OrderedReady Pod 管理
+#### OrderedReady Pod 管理   {#orderedready-pod-management}
 
 `OrderedReady` Pod 管理是 StatefulSet 的默认设置。它实现了
 [上面](#deployment-and-scaling-guarantees)描述的功能。
@@ -467,7 +467,7 @@ StatefulSet 的 `.spec.updateStrategy` 字段让
 
 `RollingUpdate`
 : `RollingUpdate` 更新策略对 StatefulSet 中的 Pod 执行自动的滚动更新。这是默认的更新策略。
- 
+
 <!--
 ## Rolling Updates
 
@@ -518,7 +518,7 @@ update, roll out a canary, or perform a phased roll out.
 <!--
 ### Maximum unavailable Pods
 -->
-### 最大不可用 Pod
+### 最大不可用 Pod   {#maximum-unavailable-pods}
 
 {{< feature-state for_k8s_version="v1.24" state="alpha" >}}
 
@@ -529,7 +529,7 @@ The value can be an absolute number (for example, `5`) or a percentage of desire
 Pods (for example, `10%`). Absolute number is calculated from the percentage value
 by rounding it up. This field cannot be 0. The default setting is 1.
 -->
-你可以通过指定 `.spec.updateStrategy.rollingUpdate.maxUnavailable` 
+你可以通过指定 `.spec.updateStrategy.rollingUpdate.maxUnavailable`
 字段来控制更新期间不可用的 Pod 的最大数量。
 该值可以是绝对值（例如，“5”）或者是期望 Pod 个数的百分比（例如，`10%`）。
 绝对值是根据百分比值四舍五入计算的。
@@ -547,13 +547,13 @@ unavailable Pod in the range `0` to `replicas - 1`, it will be counted towards
 {{< note >}}
 The `maxUnavailable` field is in Alpha stage and it is honored only by API servers
 that are running with the `MaxUnavailableStatefulSet`
-[feature gate](/docs/reference/commmand-line-tools-reference/feature-gates/)
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
 enabled.
 {{< /note >}}
 -->
 {{< note >}}
 `maxUnavailable` 字段处于 Alpha 阶段，仅当 API 服务器启用了 `MaxUnavailableStatefulSet`
-[特性门控](/zh-cn/docs/reference/commmand-line-tools-reference/feature-gates/)时才起作用。
+[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)时才起作用。
 {{< /note >}}
 
 <!--
@@ -570,7 +570,7 @@ StatefulSet will stop the rollout and wait.
 ### 强制回滚 {#forced-rollback}
 
 在默认 [Pod 管理策略](#pod-management-policies)(`OrderedReady`) 下使用
-[滚动更新](#rolling-updates) ，可能进入需要人工干预才能修复的损坏状态。
+[滚动更新](#rolling-updates)，可能进入需要人工干预才能修复的损坏状态。
 
 如果更新后 Pod 模板配置进入无法运行或就绪的状态（例如，由于错误的二进制文件
 或应用程序级配置错误），StatefulSet 将停止回滚并等待。
@@ -598,20 +598,20 @@ StatefulSet 才会开始使用被还原的模板来重新创建 Pod。
 
 {{< feature-state for_k8s_version="v1.23" state="alpha" >}}
 
-<!-- 
+<!--
 The optional `.spec.persistentVolumeClaimRetentionPolicy` field controls if
 and how PVCs are deleted during the lifecycle of a StatefulSet. You must enable the
 `StatefulSetAutoDeletePVC` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
 to use this field. Once enabled, there are two policies you can configure for each
 StatefulSet:
 -->
-在 StatefulSet 的生命周期中，可选字段 
+在 StatefulSet 的生命周期中，可选字段
 `.spec.persistentVolumeClaimRetentionPolicy` 控制是否删除以及如何删除 PVC。
 使用该字段，你必须启用 `StatefulSetAutoDeletePVC`
 [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。
 启用后，你可以为每个 StatefulSet 配置两个策略：
 
-<!-- 
+<!--
 `whenDeleted`
 : configures the volume retention behavior that applies when the StatefulSet is deleted
 
@@ -626,10 +626,10 @@ For each policy that you can configure, you can set the value to either `Delete`
 
 `whenScaled`
 : 配置当 StatefulSet 的副本数减少时应用的卷保留行为；例如，缩小集合时。
-  
+
 对于你可以配置的每个策略，你可以将值设置为 `Delete` 或 `Retain`。
 
-<!-- 
+<!--
 `Delete`
 : The PVCs created from the StatefulSet `volumeClaimTemplate` are deleted for each Pod
   affected by the policy. With the `whenDeleted` policy all PVCs from the
@@ -642,7 +642,7 @@ For each policy that you can configure, you can set the value to either `Delete`
   使用 `whenDeleted` 策略，所有来自 `volumeClaimTemplate` 的 PVC 在其 Pod 被删除后都会被删除。
   使用 `whenScaled` 策略，只有与被缩减的 Pod 副本对应的 PVC 在其 Pod 被删除后才会被删除。
 
-<!-- 
+<!--
 `Retain` (default)
 : PVCs from the `volumeClaimTemplate` are not affected when their Pod is
   deleted. This is the behavior before this new feature.
@@ -650,7 +650,7 @@ For each policy that you can configure, you can set the value to either `Delete`
 `Retain`（默认）
 : 来自 `volumeClaimTemplate` 的 PVC 在 Pod 被删除时不受影响。这是此新功能之前的行为。
 
-<!-- 
+<!--
 Bear in mind that these policies **only** apply when Pods are being removed due to the
 StatefulSet being deleted or scaled down. For example, if a Pod associated with a StatefulSet
 fails due to node failure, and the control plane creates a replacement Pod, the StatefulSet
@@ -713,7 +713,7 @@ to be garbage collected after only the condemned Pods have terminated.
 首先将已销毁的 Pod 设置为与 StatefulSet 模板 对应的 PVC 的属主。
 这会导致 PVC 仅在已废弃的 Pod 终止后被垃圾收集。
 
-<!-- 
+<!--
 This means that if the controller crashes and restarts, no Pod will be deleted before its
 owner reference has been updated appropriate to the policy. If a condemned Pod is
 force-deleted while the controller is down, the owner reference may or may not have been
@@ -730,7 +730,7 @@ deleted when Pods are force-deleted.
 出于这个原因，我们建议等待控制器恢复，控制器将在终止 Pod 之前验证属主引用。
 如果这不可行，则操作员应验证 PVC 上的属主引用，以确保在强制删除 Pod 时删除预期的对象。
 
-<!-- 
+<!--
 ### Replicas
 
 `.spec.replicas` is an optional field that specifies the number of desired Pods. It defaults to 1.
@@ -749,7 +749,7 @@ that you previously did.
 然后根据清单更新 StatefulSet（例如：通过运行 `kubectl apply -f statefulset.yaml`），
 那么应用该清单的操作会覆盖你之前所做的手动缩放。
 
-<!-- 
+<!--
 If a [HorizontalPodAutoscaler](/docs/tasks/run-application/horizontal-pod-autoscale/)
 (or any similar API for horizontal scaling) is managing scaling for a
 Statefulset, don't set `.spec.replicas`. Instead, allow the Kubernetes

content/zh-cn/docs/concepts/workloads/pods/pod-lifecycle.md

@@ -182,7 +182,7 @@ There are three possible container states: `Waiting`, `Running`, and `Terminated
 ## 容器状态  {#container-states}
 
 Kubernetes 会跟踪 Pod 中每个容器的状态，就像它跟踪 Pod 总体上的[阶段](#pod-phase)一样。
-你可以使用[容器生命周期回调](/zh-cn/docs/concepts/containers/container-lifecycle-hooks/) 
+你可以使用[容器生命周期回调](/zh-cn/docs/concepts/containers/container-lifecycle-hooks/)
 来在容器生命周期中的特定时间点触发事件。
 
 一旦{{< glossary_tooltip text="调度器" term_id="kube-scheduler" >}}将 Pod
@@ -382,7 +382,7 @@ 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).
 -->
-你所添加的 Pod 状况名称必须满足 Kubernetes 
+你所添加的 Pod 状况名称必须满足 Kubernetes
 [标签键名格式](/zh-cn/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)。
 
 <!--
@@ -484,7 +484,7 @@ Each probe must define exactly one of these four mechanisms:
   [gRPC健康检查](https://grpc.io/grpc/core/md_doc_health-checking.html)。
   如果响应的状态是 "SERVING"，则认为诊断成功。
   gRPC 探针是一个 alpha 特性，只有在你启用了
-  "GRPCContainerProbe" [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gate/)时才能使用。
+  "GRPCContainerProbe" [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)时才能使用。
 
 `httpGet`
 : 对容器的 IP 地址上指定端口和路径执行 HTTP `GET` 请求。如果响应的状态码大于等于 200
@@ -591,11 +591,11 @@ with the Pod's `restartPolicy`.
 If you'd like your container to be killed and restarted if a probe fails, then
 specify a liveness probe, and specify a `restartPolicy` of Always or OnFailure.
 -->
-如果容器中的进程能够在遇到问题或不健康的情况下自行崩溃，则不一定需要存活态探针; 
+如果容器中的进程能够在遇到问题或不健康的情况下自行崩溃，则不一定需要存活态探针;
-`kubelet` 将根据 Pod 的`restartPolicy` 自动执行修复操作。
+`kubelet` 将根据 Pod 的 `restartPolicy` 自动执行修复操作。
 
 如果你希望容器在探测失败时被杀死并重新启动，那么请指定一个存活态探针，
-并指定`restartPolicy` 为 "`Always`" 或 "`OnFailure`"。
+并指定 `restartPolicy` 为 "`Always`" 或 "`OnFailure`"。
 
 <!--
 #### When should you use a readiness probe?
@@ -754,7 +754,7 @@ An example flow:
    如果你使用 `kubectl describe` 来查验你正在删除的 Pod，该 Pod 会显示为
    "Terminating" （正在终止）。
    在 Pod 运行所在的节点上：`kubelet` 一旦看到 Pod
-   被标记为正在终止（已经设置了体面终止限期），`kubelet` 即开始本地的 Pod 关闭过程。 
+   被标记为正在终止（已经设置了体面终止限期），`kubelet` 即开始本地的 Pod 关闭过程。
 
    <!--
    1. If one of the Pod's containers has defined a `preStop`