diff --git a/content/zh-cn/docs/concepts/workloads/pods/_index.md b/content/zh-cn/docs/concepts/workloads/pods/_index.md index c5f4aac045089..55f2888e375dc 100644 --- a/content/zh-cn/docs/concepts/workloads/pods/_index.md +++ b/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/)的情况下， +为调试的目的注入临时性容器。 @@ -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 >}} Pod 的共享上下文包括一组 Linux 名字空间、控制组（cgroup）和可能一些其他的隔离方面， -即用来隔离 Docker 容器的技术。 +即用来隔离{{< glossary_tooltip text="容器" term_id="container" >}}的技术。 在 Pod 的上下文中，每个独立的应用可能会进一步实施隔离。 -就 Docker 概念的术语而言，Pod 类似于共享名字空间和文件系统卷的一组 Docker 容器。 +Pod 类似于共享名字空间并共享文件系统卷的一组容器。 * **运行单个容器的 Pod**。"每个 Pod 一个容器" 模型是最常见的 Kubernetes 用例； 在这种情况下，可以将 Pod 看作单个容器的包装器，并且 Kubernetes 直接管理 Pod，而不是容器。 @@ -163,6 +156,11 @@ Kubernetes 集群中的 Pod 主要有两种用法： Pod 将这些容器和存储资源打包为一个可管理的实体。 {{< note >}} + 将多个并置、同管的容器组织到一个 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/)。 -{{< note >}} -你的{{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}} -必须支持特权容器的概念才能使用这一配置。 +你的{{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}必须支持特权容器的概念才能使用这一配置。 {{< /note >}} 静态 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/)。