Merge pull request #36848 from windsonsea/podyhf

[zh]Sync /concepts/workloads/pods/_index.md

Author: k8s-ci-robot

content/zh-cn/docs/concepts/workloads/pods/_index.md

@@ -50,8 +50,8 @@ for debugging if your cluster offers this.
 -->
 除了应用容器，Pod 还可以包含在 Pod 启动期间运行的
 [Init 容器](/zh-cn/docs/concepts/workloads/pods/init-containers/)。
-你也可以在集群中支持[临时性容器](/zh-cn/docs/concepts/workloads/pods/ephemeral-containers/)
-的情况下，为调试的目的注入临时性容器。
+你也可以在集群支持[临时性容器](/zh-cn/docs/concepts/workloads/pods/ephemeral-containers/)的情况下，
+为调试的目的注入临时性容器。
 
 <!-- body -->
 
@@ -64,26 +64,23 @@ than just Docker, [Docker](https://www.docker.com/) is the most commonly known
 runtime, and it helps to describe Pods using some terminology from Docker.
 -->
 {{< note >}}
-除了 Docker 之外，Kubernetes 支持
-很多其他{{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}，
+除了 Docker 之外，Kubernetes 支持很多其他{{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}，
 [Docker](https://www.docker.com/) 是最有名的运行时，
 使用 Docker 的术语来描述 Pod 会很有帮助。
 {{< /note >}}
 
 <!--
 The shared context of a Pod is a set of Linux namespaces, cgroups, and
-potentially other facets of isolation - the same things that isolate a Docker
-container.  Within a Pod's context, the individual applications may have
+potentially other facets of isolation - the same things that isolate a {{< glossary_tooltip text="container" term_id="container" >}}. Within a Pod's context, the individual applications may have
 further sub-isolations applied.
 
-In terms of Docker concepts, a Pod is similar to a group of Docker containers
-with shared namespaces and shared filesystem volumes.
+A Pod is similar to a set of containers with shared namespaces and shared filesystem volumes.
 -->
 Pod 的共享上下文包括一组 Linux 名字空间、控制组（cgroup）和可能一些其他的隔离方面，
-即用来隔离 Docker 容器的技术。
+即用来隔离{{< glossary_tooltip text="容器" term_id="container" >}}的技术。
 在 Pod 的上下文中，每个独立的应用可能会进一步实施隔离。
 
-就 Docker 概念的术语而言，Pod 类似于共享名字空间和文件系统卷的一组 Docker 容器。
+Pod 类似于共享名字空间并共享文件系统卷的一组容器。
 
 <!--
 ## Using Pods
@@ -116,7 +113,7 @@ with workload resources.
 Pod 通常不是直接创建的，而是使用工作负载资源创建的。
 有关如何将 Pod 用于工作负载资源的更多信息，请参阅[使用 Pod](#working-with-pods)。
 
-### 用于管理 pod 的工作负载资源
+### 用于管理 pod 的工作负载资源   {#workload-resources-for-managing-pods}
 
 <!--
 Usually you don't need to create Pods directly, even singleton Pods. 
@@ -149,10 +146,6 @@ Kubernetes 集群中的 Pod 主要有两种用法：
   refreshes or updates those files.  
   The Pod wraps these containers, storage resources, and an ephemeral network
   identity together as a single unit.
-
-  Grouping multiple co-located and co-managed containers in a single Pod is a
-  relatively advanced use case. You should use this pattern only in specific
-  instances in which your containers are tightly coupled.
 -->
 * **运行单个容器的 Pod**。"每个 Pod 一个容器" 模型是最常见的 Kubernetes 用例；
   在这种情况下，可以将 Pod 看作单个容器的包装器，并且 Kubernetes 直接管理 Pod，而不是容器。
@@ -163,6 +156,11 @@ Kubernetes 集群中的 Pod 主要有两种用法：
   Pod 将这些容器和存储资源打包为一个可管理的实体。
 
   {{< note >}}
+  <!--
+  Grouping multiple co-located and co-managed containers in a single Pod is a
+  relatively advanced use case. You should use this pattern only in specific
+  instances in which your containers are tightly coupled.
+  -->
   将多个并置、同管的容器组织到一个 Pod 中是一种相对高级的使用场景。
   只有在一些场景中，容器之间紧密关联时你才应该使用这种模式。  
   {{< /note >}}
@@ -183,8 +181,7 @@ scaling and auto-healing.
 每个 Pod 都旨在运行给定应用程序的单个实例。如果希望横向扩展应用程序
 （例如，运行多个实例以提供更多的资源），则应该使用多个 Pod，每个实例使用一个 Pod。
 在 Kubernetes 中，这通常被称为**副本（Replication）**。
-通常使用一种工作负载资源及其{{< glossary_tooltip text="控制器" term_id="controller" >}}
-来创建和管理一组 Pod 副本。
+通常使用一种工作负载资源及其{{< glossary_tooltip text="控制器" term_id="controller" >}}来创建和管理一组 Pod 副本。
 
 参见 [Pod 和控制器](#pods-and-controllers)以了解 Kubernetes
 如何使用工作负载资源及其控制器以实现应用的扩缩和自动修复。
@@ -198,7 +195,7 @@ co-scheduled on the same physical or virtual machine in the cluster. The contain
 can share resources and dependencies, communicate with one another, and coordinate
 when and how they are terminated.
 -->
-### Pod 怎样管理多个容器
+### Pod 怎样管理多个容器   {#how-pods-manage-multiple-containers}
 
 Pod 被设计成支持形成内聚服务单元的多个协作过程（形式为容器）。
 Pod 中的容器被自动安排到集群中的同一物理机或虚拟机上，并可以一起进行调度。
@@ -333,7 +330,7 @@ PodTemplates are specifications for creating Pods, and are included in workload
 -->
 ### Pod 模板    {#pod-templates}
 
-{{< glossary_tooltip text="负载" term_id="workload" >}}资源的控制器通常使用
+{{< glossary_tooltip text="工作负载" term_id="workload" >}}资源的控制器通常使用
 **Pod 模板（Pod Template）**来替你创建 Pod 并管理它们。
 
 Pod 模板是包含在工作负载对象中的规范，用来创建 Pod。这类负载资源包括
@@ -405,8 +402,8 @@ details are abstracted away. That abstraction and separation of concerns simplif
 system semantics, and makes it feasible to extend the cluster's behavior without
 changing existing code.
 -->
-在节点上，{{< glossary_tooltip term_id="kubelet" text="kubelet" >}} 并不直接监测
-或管理与 Pod 模板相关的细节或模板的更新，这些细节都被抽象出来。
+在节点上，{{< glossary_tooltip term_id="kubelet" text="kubelet" >}} 并不直接监测或管理与
+Pod 模板相关的细节或模板的更新，这些细节都被抽象出来。
 这种抽象和关注点分离简化了整个系统的语义，
 并且使得用户可以在不改变现有代码的前提下就能扩展集群的行为。
 
@@ -430,8 +427,7 @@ like
 [`replace`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#replace-pod-v1-core)
 have some limitations:
 -->
-Kubernetes 并不禁止你直接管理 Pod。对运行中的 Pod 的某些字段执行就地更新操作
-还是可能的。不过，类似
+Kubernetes 并不禁止你直接管理 Pod。对运行中的 Pod 的某些字段执行就地更新操作还是可能的。不过，类似
 [`patch`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#patch-pod-v1-core) 和
 [`replace`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#replace-pod-v1-core)
 这类更新操作有一些限制：
@@ -493,7 +489,7 @@ Kubernetes implements shared storage and makes it available to Pods.
 Pod 中的所有容器都可以访问该共享卷，从而允许这些容器共享数据。
 卷还允许 Pod 中的持久数据保留下来，即使其中的容器需要重新启动。
 有关 Kubernetes 如何在 Pod 中实现共享存储并将其提供给 Pod 的更多信息，
-请参考[卷](/zh-cn/docs/concepts/storage/)。
+请参考[存储](/zh-cn/docs/concepts/storage/)。
 
 <!--
 ### Pod networking
@@ -554,12 +550,11 @@ If your cluster has the `WindowsHostProcessContainers` feature enabled, you can
 这些 Pod 中的所有容器都必须以 Windows HostProcess 容器方式运行。
 HostProcess Pod 可以直接运行在主机上，它也能像 Linux 特权容器一样，用于执行管理任务。
 
+{{< note >}}
 <!--
 Your {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}} must support the concept of a privileged container for this setting to be relevant.
 -->
-{{< note >}}
-你的{{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}
-必须支持特权容器的概念才能使用这一配置。
+你的{{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}必须支持特权容器的概念才能使用这一配置。
 {{< /note >}}
 
 <!--
@@ -591,11 +586,11 @@ but cannot be controlled from there.
 -->
 静态 Pod 通常绑定到某个节点上的 {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}。
 其主要用途是运行自托管的控制面。
-在自托管场景中，使用 `kubelet` 来管理各个独立的
-[控制面组件](/zh-cn/docs/concepts/overview/components/#control-plane-components)。
+在自托管场景中，使用 `kubelet`
+来管理各个独立的[控制面组件](/zh-cn/docs/concepts/overview/components/#control-plane-components)。
 
-`kubelet` 自动尝试为每个静态 Pod 在 Kubernetes API 服务器上创建一个
-{{< glossary_tooltip text="镜像 Pod" term_id="mirror-pod" >}}。
+`kubelet` 自动尝试为每个静态 Pod 在 Kubernetes API
+服务器上创建一个{{< glossary_tooltip text="镜像 Pod" term_id="mirror-pod" >}}。
 这意味着在节点上运行的 Pod 在 API 服务器上是可见的，但不可以通过 API 服务器来控制。
 
 {{< note >}}
@@ -647,15 +642,15 @@ in the Pod Lifecycle documentation.
 * Read about [Pod topology spread constraints](/docs/concepts/scheduling-eviction/topology-spread-constraints/).
 -->
 * 了解 [Pod 生命周期](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/)。
-* 了解 [RuntimeClass](/zh-cn/docs/concepts/containers/runtime-class/)，以及如何使用它
-  来配置不同的 Pod 使用不同的容器运行时配置。
-* 了解 [PodDisruptionBudget](/zh-cn/docs/concepts/workloads/pods/disruptions/)，以及你
-  如何可以利用它在出现干扰因素时管理应用的可用性。
+* 了解 [RuntimeClass](/zh-cn/docs/concepts/containers/runtime-class/)，
+  以及如何使用它来配置不同的 Pod 使用不同的容器运行时配置。
+* 了解 [PodDisruptionBudget](/zh-cn/docs/concepts/workloads/pods/disruptions/)，
+  以及你可以如何利用它在出现干扰因素时管理应用的可用性。
 * Pod 在 Kubernetes REST API 中是一个顶层资源。
   {{< api-reference page="workload-resources/pod-v1" >}}
   对象的定义中包含了更多的细节信息。
-* 博客 [分布式系统工具箱：复合容器模式](/blog/2015/06/the-distributed-system-toolkit-patterns/)
-  中解释了在同一 Pod 中包含多个容器时的几种常见布局。
+* 博客[分布式系统工具箱：复合容器模式](/blog/2015/06/the-distributed-system-toolkit-patterns/)中解释了在同一
+  Pod 中包含多个容器时的几种常见布局。
 * 了解 [Pod 拓扑分布约束](/zh-cn/docs/concepts/scheduling-eviction/topology-spread-constraints/)。
 
 <!--