[zh] Resync concepts section (7)

content/zh/docs/concepts/workloads/pods/disruptions.md

@@ -5,6 +5,10 @@ weight: 60
 ---
 
 <!--
+reviewers:
+- erictune
+- foxish
+- davidopp
 title: Disruptions
 content_type: concept
 weight: 60
@@ -136,18 +140,18 @@ Here are some ways to mitigate involuntary disruptions:
 [stateless](/docs/tasks/run-application/run-stateless-application-deployment/)
 and [stateful](/docs/tasks/run-application/run-replicated-stateful-application/) applications.)
 - For even higher availability when running replicated applications,
-spread applications across racks (using
+  spread applications across racks (using
-[anti-affinity](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature))
+  [anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity))
-or across zones (if using a
+  or across zones (if using a
-[multi-zone cluster](/docs/setup/multiple-zones).)
+  [multi-zone cluster](/docs/setup/multiple-zones).)
 -->
 - 确保 Pod 在请求中给出[所需资源](/zh/docs/tasks/configure-pod-container/assign-memory-resource/)。
 - 如果需要更高的可用性，请复制应用程序。
   （了解有关运行多副本的[无状态](/zh/docs/tasks/run-application/run-stateless-application-deployment/)
   和[有状态](/zh/docs/tasks/run-application/run-replicated-stateful-application/)应用程序的信息。）
 - 为了在运行复制应用程序时获得更高的可用性，请跨机架（使用
-  [反亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/)）或跨区域
+  [反亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)
-  （如果使用[多区域集群](/zh/docs/setup/best-practices/multiple-zones/)）扩展应用程序。
+  或跨区域（如果使用[多区域集群](/zh/docs/setup/best-practices/multiple-zones/)）扩展应用程序。
 
 <!--
 The frequency of voluntary disruptions varies.  On a basic Kubernetes cluster, there are
@@ -186,9 +190,9 @@ number needed for a quorum. A web front end might want to
 ensure that the number of replicas serving load never falls below a certain
 percentage of the total.
 -->
-## 干扰预算
+## 干扰预算   {#pod-disruption-budgets}
 
-{{< feature-state for_k8s_version="v1.5" state="beta" >}}
+{{< feature-state for_k8s_version="v1.21" state="stable" >}}
 
 即使你会经常引入自愿性干扰，Kubernetes 也能够支持你运行高度可用的应用。
 
@@ -199,11 +203,11 @@ Web 前端可能希望确保提供负载的副本数量永远不会低于总数
 
 <!--
 Cluster managers and hosting providers should use tools which
-respect Pod Disruption Budgets by calling the [Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)
+respect PodDisruptionBudgets by calling the [Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#eviction-api)
 instead of directly deleting pods or deployments.  Examples are the `kubectl drain` command
 and the Kubernetes-on-GCE cluster upgrade script (`cluster/gce/upgrade.sh`).
 -->
-集群管理员和托管提供商应该使用遵循 Pod Disruption Budgets 的接口
+集群管理员和托管提供商应该使用遵循 PodDisruptionBudgets 的接口
 （通过调用[Eviction API](/zh/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)），
 而不是直接删除 Pod 或 Deployment。
 
@@ -264,7 +268,7 @@ during application updates is configured in spec for the specific workload resou
 When a pod is evicted using the eviction API, it is gracefully
 [terminated](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination),
 hornoring the 
-`terminationGracePeriodSeconds` setting in its [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).)
+`terminationGracePeriodSeconds` setting in its [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).
 -->
 当使用驱逐 API 驱逐 Pod 时，Pod 会被体面地
 [终止](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)，期间会

content/zh/docs/concepts/workloads/pods/ephemeral-containers.md

@@ -20,10 +20,12 @@ that runs temporarily in an existing {{< glossary_tooltip term_id="pod" >}} to
 accomplish user-initiated actions such as troubleshooting. You use ephemeral
 containers to inspect services rather than to build applications.
 -->
-本页面概述了临时容器：一种特殊的容器，该容器在现有 {{< glossary_tooltip text="Pod" term_id="pod" >}}
+本页面概述了临时容器：一种特殊的容器，该容器在现有
+{{< glossary_tooltip text="Pod" term_id="pod" >}}
 中临时运行，以便完成用户发起的操作，例如故障排查。
 你会使用临时容器来检查服务，而不是用它来构建应用程序。
 
+{{< warning >}}
 <!--
 Ephemeral containers are in early alpha state and are not suitable for production
 clusters. You should expect the feature not to work in some situations, such as
@@ -31,11 +33,10 @@ when targeting the namespaces of a container. In accordance with the [Kubernetes
 Deprecation Policy](/docs/reference/using-api/deprecation-policy/), this alpha
 feature could change significantly in the future or be removed entirely.
 -->
-{{< warning >}}
+临时容器处于早期的 Alpha 阶段，不适用于生产环境集群。
-临时容器处于早期的 alpha 阶段，不适用于生产环境集群。
 应该预料到临时容器在某些情况下不起作用，例如在定位容器的命名空间时。
 根据 [Kubernetes 弃用政策](/zh/docs/reference/using-api/deprecation-policy/)，
-此 alpha 功能将来可能发生重大变化或被完全删除。
+此 Alpha 功能将来可能发生重大变化或被完全删除。
 {{< /warning >}}
 
 <!-- body -->
@@ -49,7 +50,7 @@ replaceable, you cannot add a container to a Pod once it has been created.
 Instead, you usually delete and replace Pods in a controlled fashion using
 {{< glossary_tooltip text="deployments" term_id="deployment" >}}.
 -->
-## 了解临时容器
+## 了解临时容器   {#understanding-ephemeral-containers}
 
 {{< glossary_tooltip text="Pod" term_id="pod" >}} 是 Kubernetes 应用程序的基本构建块。
 由于 Pod 是一次性且可替换的，因此一旦 Pod 创建，就无法将容器加入到 Pod 中。
@@ -74,7 +75,7 @@ they are not appropriate for building applications.  Ephemeral containers are
 described using the same `ContainerSpec` as regular containers, but many fields
 are incompatible and disallowed for ephemeral containers.
 -->
-### 什么是临时容器？
+### 什么是临时容器？    {#what-is-an-ephemeral-container}
 
 临时容器与其他容器的不同之处在于，它们缺少对资源或执行的保证，并且永远不会自动重启，
 因此不适用于构建应用程序。
@@ -89,9 +90,7 @@ are incompatible and disallowed for ephemeral containers.
 -->
 - 临时容器没有端口配置，因此像 `ports`，`livenessProbe`，`readinessProbe`
   这样的字段是不允许的。
-
 - Pod 资源分配是不可变的，因此 `resources` 配置是不允许的。
-
 - 有关允许字段的完整列表，请参见
   [EphemeralContainer 参考文档](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ephemeralcontainer-v1-core)。
 
@@ -116,7 +115,7 @@ Ephemeral containers are useful for interactive troubleshooting when `kubectl
 exec` is insufficient because a container has crashed or a container image
 doesn't include debugging utilities.
 -->
-## 临时容器的用途
+## 临时容器的用途   {#uses-for-ephemeral-containers}
 
 当由于容器崩溃或容器镜像不包含调试工具而导致 `kubectl exec` 无用时，
 临时容器对于交互式故障排查很有用。
@@ -128,7 +127,7 @@ and exposure to bugs and vulnerabilities. Since distroless images do not include
 shell or any debugging utilities, it's difficult to troubleshoot distroless
 images using `kubectl exec` alone.
 -->
-尤其是，[distroless 镜像](https://github.com/GoogleContainerTools/distroless)
+尤其是，[Distroless 镜像](https://github.com/GoogleContainerTools/distroless)
 允许用户部署最小的容器镜像，从而减少攻击面并减少故障和漏洞的暴露。
 由于 distroless 镜像不包含 Shell 或任何的调试工具，因此很难单独使用
 `kubectl exec` 命令进行故障排查。
@@ -138,19 +137,28 @@ When using ephemeral containers, it's helpful to enable [process namespace
 sharing](/docs/tasks/configure-pod-container/share-process-namespace/) so
 you can view processes in other containers.
 -->
-使用临时容器时，启用[进程名字空间共享](/zh/docs/tasks/configure-pod-container/share-process-namespace/)
+使用临时容器时，启用
+[进程名字空间共享](/zh/docs/tasks/configure-pod-container/share-process-namespace/)
 很有帮助，可以查看其他容器中的进程。
 
 <!--
-### Examples
+See [Debugging with Ephemeral Debug Container](/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)
+for examples of troubleshooting using ephemeral containers.
+-->
+关于如何使用临时容器来执行故障排查的例子，可参阅
+[使用临时调试容器来调试](/zh/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)。
 
+<!--
+## Ephemeral containers API
+-->
+### 临时容器 API   {#ephemeral-containers-api}」
+
+{{< note >}}
+<!--
 The examples in this section require the `EphemeralContainers` [feature
 gate](/docs/reference/command-line-tools-reference/feature-gates/) to be
 enabled, and Kubernetes client and server version v1.16 or later.
 -->
-### 示例
-
-{{< note >}}
 本节中的示例要求启用 `EphemeralContainers`
 [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)，
 并且 kubernetes 客户端和服务端版本要求为 v1.16 或更高版本。
@@ -180,7 +188,7 @@ the ephemeral container to add as an `EphemeralContainers` list:
     "apiVersion": "v1",
     "kind": "EphemeralContainers",
     "metadata": {
-            "name": "example-pod"
+        "name": "example-pod"
     },
     "ephemeralContainers": [{
         "command": [
@@ -281,34 +289,3 @@ You can attach to the new ephemeral container using `kubectl attach`:
 kubectl attach -it example-pod -c debugger
 ```
 
-<!--
-If process namespace sharing is enabled, you can see processes from all the containers in that Pod.
-For example, after attaching, you run `ps` in the debugger container:
--->
-如果启用了进程命名空间共享，则可以查看该 Pod 所有容器中的进程。
-例如，运行上述 `attach` 操作后，在调试器容器中运行 `ps` 操作：
-
-```shell
-# 在 "debugger" 临时容器内中运行此 shell 命令
-ps auxww
-```
-
-运行命令后，输出类似于：
-
-```
-PID   USER     TIME  COMMAND
-    1 root      0:00 /pause
-    6 root      0:00 nginx: master process nginx -g daemon off;
-   11 101       0:00 nginx: worker process
-   12 101       0:00 nginx: worker process
-   13 101       0:00 nginx: worker process
-   14 101       0:00 nginx: worker process
-   15 101       0:00 nginx: worker process
-   16 101       0:00 nginx: worker process
-   17 101       0:00 nginx: worker process
-   18 101       0:00 nginx: worker process
-   19 root      0:00 /pause
-   24 root      0:00 sh
-   29 root      0:00 ps auxww
-```
-

content/zh/docs/concepts/workloads/pods/init-containers.md

@@ -1,6 +1,4 @@
 ---
-approvers:
-- erictune
 title: Init 容器
 content_type: concept
 weight: 40
@@ -514,9 +512,6 @@ Pod 级别的 cgroups 是基于有效 Pod 的请求和限制值，和调度器
 A Pod can restart, causing re-execution of init containers, for the following
 reasons:
 
-* A user updates the Pod specification, causing the init container image to change.
-  Any changes to the init container image restarts the Pod. App container image
-  changes only restart the app container.
 * The Pod infrastructure container is restarted. This is uncommon and would
   have to be done by someone with root access to nodes.
 * All containers in a Pod are terminated while `restartPolicy` is set to Always,
@@ -527,15 +522,22 @@ reasons:
 
 Pod 重启会导致 Init 容器重新执行，主要有如下几个原因：
 
-* 用户更新 Pod 的规约导致 Init 容器镜像发生改变。Init 容器镜像的变更会引起 Pod 重启。
-  应用容器镜像的变更仅会重启应用容器。
-
 * Pod 的基础设施容器 (译者注：如 `pause` 容器) 被重启。这种情况不多见，
   必须由具备 root 权限访问节点的人员来完成。
 
 * 当 `restartPolicy` 设置为 "`Always`"，Pod 中所有容器会终止而强制重启。
   由于垃圾收集机制的原因，Init 容器的完成记录将会丢失。
 
+<!--
+The Pod will not be restarted when the init container image is changed, or the
+init container completion record has been lost due to garbage collection. This
+applies for Kubernetes v1.20 and later. If you are using an earlier version of
+Kubernetes, consult the documentation for the version you are using.
+-->
+当 Init 容器的镜像发生改变或者 Init 容器的完成记录因为垃圾收集等原因被丢失时，
+Pod 不会被重启。这一行为适用于 Kubernetes v1.20 及更新版本。如果你在使用较早
+版本的 Kubernetes，可查阅你所使用的版本对应的文档。
+
 ## {{% heading "whatsnext" %}}
 
 <!--

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

@@ -74,18 +74,17 @@ ID（[UID](/zh/docs/concepts/overview/working-with-objects/names/#uids)），
 
 <!--
 Pods do not, by themselves, self-heal. If a Pod is scheduled to a
-{{< glossary_tooltip text="node" term_id="node" >}} that then fails,
+{{< glossary_tooltip text="node" term_id="node" >}} that then fails, the Pod is deleted; likewise, a Pod won't
-or if the scheduling operation itself 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.
 -->
 Pod 自身不具有自愈能力。如果 Pod 被调度到某{{< glossary_tooltip text="节点" term_id="node" >}}
-而该节点之后失效，或者调度操作本身失效，Pod 会被删除；与此类似，Pod 无法在节点资源
+而该节点之后失效，Pod 会被删除；类似地，Pod 无法在因节点资源
-耗尽或者节点维护期间继续存活。Kubernetes 使用一种高级抽象，称作
+耗尽或者节点维护而被驱逐期间继续存活。Kubernetes 使用一种高级抽象
-{{< glossary_tooltip term_id="controller" text="控制器" >}}，来管理这些相对而言
+来管理这些相对而言可随时丢弃的 Pod 实例，称作
-可随时丢弃的 Pod 实例。
+{{< glossary_tooltip term_id="controller" text="控制器" >}}。
 
 <!--
 A given Pod (as defined by a UID) is never "rescheduled" to a different node; instead,
@@ -577,14 +576,14 @@ is different from the liveness probe.
 如果你希望容器能够自行进入维护状态，也可以指定一个就绪态探针，检查某个特定于
 就绪态的因此不同于存活态探测的端点。
 
+{{< note >}}
 <!--
-If you just want to be able to drain requests when the Pod is deleted, you do not
+If you want to be able to drain requests when the Pod is deleted, you do not
 necessarily need a readiness probe; on deletion, the Pod automatically puts itself
 into an unready state regardless of whether the readiness probe exists.
 The Pod remains in the unready state while it waits for the containers in the Pod
 to stop.
 -->
-{{< note >}}
 请注意，如果你只是想在 Pod 被删除时能够排空请求，则不一定需要使用就绪态探针；
 在删除 Pod 时，Pod 会自动将自身置于未就绪状态，无论就绪态探针是否存在。
 等待 Pod 中的容器停止期间，Pod 会一直处于未就绪状态。
@@ -677,18 +676,6 @@ An example flow:
    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.
-
-   1. If one of the Pod's containers has defined a `preStop`
-      [hook](/docs/concepts/containers/container-lifecycle-hooks/#hook-details), 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.
-      If the `preStop` hook needs longer to complete than the default grace period allows,
-      you must modify `terminationGracePeriodSeconds` to suit this.
-   1. The kubelet triggers the container runtime to send a TERM signal to process 1 inside each
-      container.
-      The containers in the Pod receive the TERM signal at different times and in an arbitrary
-      order. If the order of shutdowns matters, consider using a `preStop` hook to synchronize.
 -->
 下面是一个例子：
 
@@ -701,6 +688,19 @@ An example flow:
    在 Pod 运行所在的节点上：`kubelet` 一旦看到 Pod
    被标记为正在终止（已经设置了体面终止限期），`kubelet` 即开始本地的 Pod 关闭过程。 
 
+   <!--
+   1. If one of the Pod's containers has defined a `preStop`
+      [hook](/docs/concepts/containers/container-lifecycle-hooks/#hook-details), 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.
+      If the `preStop` hook needs longer to complete than the default grace period allows,
+      you must modify `terminationGracePeriodSeconds` to suit this.
+   1. The kubelet triggers the container runtime to send a TERM signal to process 1 inside each
+      container.
+      The containers in the Pod receive the TERM signal at different times and in an arbitrary
+      order. If the order of shutdowns matters, consider using a `preStop` hook to synchronize.
+   -->
    1. 如果 Pod 中的容器之一定义了 `preStop`
       [回调](/zh/docs/concepts/containers/container-lifecycle-hooks/#hook-details)，
       `kubelet` 开始在容器内运行该回调逻辑。如果超出体面终止限期时，`preStop` 回调逻辑
@@ -847,7 +847,6 @@ This avoids a resource leak as Pods are created and terminated over time.
 and
 [ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core).
 -->
-
 * 动手实践[为容器生命周期时间关联处理程序](/zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)。
 * 动手实践[配置存活态、就绪态和启动探针](/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)。
 * 进一步了解[容器生命周期回调](/zh/docs/concepts/containers/container-lifecycle-hooks/)。

content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md

@@ -95,10 +95,11 @@ graph TB
 {{< /mermaid >}}
 
 <!--
-Instead of manually applying labels, you can also reuse the [well-known labels](/docs/reference/kubernetes-api/labels-annotations-taints/) that are created and populated automatically on most clusters.
+
+Instead of manually applying labels, you can also reuse the [well-known labels](/docs/reference/labels-annotations-taints/) that are created and populated automatically on most clusters.
 -->
 你可以复用在大多数集群上自动创建和填充的
-[常用标签](/zh/docs/reference/kubernetes-api/labels-annotations-taints/)，
+[常用标签](/zh/docs/reference/labels-annotations-taints/)，
 而不是手动添加标签。
 
 <!--