From 4220852973196b43feae614fb0e64905f0926305 Mon Sep 17 00:00:00 2001 From: Michael Date: Tue, 5 Jul 2022 23:25:55 +0800 Subject: [PATCH] [zh-cn] Improve concepts/workloads/pods/_index.md --- .../docs/concepts/workloads/pods/_index.md | 116 +++++++++--------- 1 file changed, 55 insertions(+), 61 deletions(-) diff --git a/content/zh-cn/docs/concepts/workloads/pods/_index.md b/content/zh-cn/docs/concepts/workloads/pods/_index.md index 12063e1e84..0d09c4e435 100644 --- a/content/zh-cn/docs/concepts/workloads/pods/_index.md +++ b/content/zh-cn/docs/concepts/workloads/pods/_index.md @@ -1,5 +1,5 @@ --- -title: Pods +title: Pod content_type: concept weight: 10 no_list: true @@ -33,16 +33,15 @@ application-specific "logical host": it contains one or more application containers which are relatively tightly coupled. In non-cloud contexts, applications executed on the same physical or virtual machine are analogous to cloud applications executed on the same logical host. --> -_Pod_ 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。 +**Pod** 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。 -_Pod_ （就像在鲸鱼荚或者豌豆荚中）是一组（一个或多个） +**Pod**（就像在鲸鱼荚或者豌豆荚中）是一组（一个或多个） {{< glossary_tooltip text="容器" term_id="container" >}}； 这些容器共享存储、网络、以及怎样运行这些容器的声明。 Pod 中的内容总是并置（colocated）的并且一同调度，在共享的上下文中运行。 -Pod 所建模的是特定于应用的“逻辑主机”，其中包含一个或多个应用容器， -这些容器是相对紧密的耦合在一起的。 -在非云环境中，在相同的物理机或虚拟机上运行的应用类似于 -在同一逻辑主机上运行的云应用。 +Pod 所建模的是特定于应用的 “逻辑主机”，其中包含一个或多个应用容器， +这些容器相对紧密地耦合在一起。 +在非云环境中，在相同的物理机或虚拟机上运行的应用类似于在同一逻辑主机上运行的云应用。 -Pod 的共享上下文包括一组 Linux 名字空间、控制组（cgroup）和可能一些其他的隔离 -方面，即用来隔离 Docker 容器的技术。 +Pod 的共享上下文包括一组 Linux 名字空间、控制组（cgroup）和可能一些其他的隔离方面， +即用来隔离 Docker 容器的技术。 在 Pod 的上下文中，每个独立的应用可能会进一步实施隔离。 -就 Docker 概念的术语而言，Pod 类似于共享名字空间和文件系统卷的一组 Docker -容器。 +就 Docker 概念的术语而言，Pod 类似于共享名字空间和文件系统卷的一组 Docker 容器。 Pod 通常不是直接创建的，而是使用工作负载资源创建的。 -有关如何将 Pod 用于工作负载资源的更多信息，请参阅 [使用 Pod](#working-with-pods)。 +有关如何将 Pod 用于工作负载资源的更多信息，请参阅[使用 Pod](#working-with-pods)。 ### 用于管理 pod 的工作负载资源 @@ -134,10 +132,9 @@ Pods in a Kubernetes cluster are used in two main ways: 通常你不需要直接创建 Pod，甚至单实例 Pod。 相反，你会使用诸如 {{< glossary_tooltip text="Deployment" term_id="deployment" >}} 或 -{{< glossary_tooltip text="Job" term_id="job" >}} 这类工作负载资源 -来创建 Pod。如果 Pod 需要跟踪状态， -可以考虑 {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} -资源。 +{{< glossary_tooltip text="Job" term_id="job" >}} 这类工作负载资源来创建 Pod。 +如果 Pod 需要跟踪状态，可以考虑 +{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} 资源。 Kubernetes 集群中的 Pod 主要有两种用法： @@ -159,12 +156,12 @@ Kubernetes 集群中的 Pod 主要有两种用法： relatively advanced use case. You should use this pattern only in specific instances in which your containers are tightly coupled. --> -* **运行单个容器的 Pod**。"每个 Pod 一个容器"模型是最常见的 Kubernetes 用例； +* **运行单个容器的 Pod**。"每个 Pod 一个容器" 模型是最常见的 Kubernetes 用例； 在这种情况下，可以将 Pod 看作单个容器的包装器，并且 Kubernetes 直接管理 Pod，而不是容器。 * **运行多个协同工作的容器的 Pod**。 Pod 可能封装由多个紧密耦合且需要共享资源的共处容器组成的应用程序。 这些位于同一位置的容器可能形成单个内聚的服务单元 —— 一个容器将文件从共享卷提供给公众， - 而另一个单独的“边车”（sidecar）容器则刷新或更新这些文件。 + 而另一个单独的 “边车”（sidecar）容器则刷新或更新这些文件。 Pod 将这些容器和存储资源打包为一个可管理的实体。 {{< note >}} @@ -185,9 +182,9 @@ Kubernetes uses workload resources, and their controllers, to implement applicat scaling and auto-healing. --> -每个 Pod 都旨在运行给定应用程序的单个实例。如果希望横向扩展应用程序（例如，运行多个实例 -以提供更多的资源），则应该使用多个 Pod，每个实例使用一个 Pod。 -在 Kubernetes 中，这通常被称为 _副本（Replication）_。 +每个 Pod 都旨在运行给定应用程序的单个实例。如果希望横向扩展应用程序 +（例如，运行多个实例以提供更多的资源），则应该使用多个 Pod，每个实例使用一个 Pod。 +在 Kubernetes 中，这通常被称为**副本（Replication）**。 通常使用一种工作负载资源及其{{< glossary_tooltip text="控制器" term_id="controller" >}} 来创建和管理一组 Pod 副本。 @@ -218,7 +215,7 @@ that updates those files from a remote source, as in the following diagram: 例如，你可能有一个容器，为共享卷中的文件提供 Web 服务器支持，以及一个单独的 "边车 (sidercar)" 容器负责从远端更新这些文件，如下图所示： -{{< figure src="/images/docs/pod.svg" alt="Pod creation diagram" class="diagram-medium" >}} +{{< figure src="/images/docs/pod.svg" alt="Pod 创建示意图" class="diagram-medium" >}} -有些 Pod 具有 {{< glossary_tooltip text="Init 容器" term_id="init-container" >}} 和 +有些 Pod 具有 {{< glossary_tooltip text="Init 容器" term_id="init-container" >}}和 {{< glossary_tooltip text="应用容器" term_id="app-container" >}}。 Init 容器会在启动应用容器之前运行并完成。 -Pod 天生地为其成员容器提供了两种共享资源：[网络](#pod-networking)和 -[存储](#pod-storage)。 +Pod 天生地为其成员容器提供了两种共享资源：[网络](#pod-networking)和[存储](#pod-storage)。 -### Pod 模版 {#pod-templates} +### Pod 模板 {#pod-templates} {{< glossary_tooltip text="负载" term_id="workload" >}}资源的控制器通常使用 -_Pod 模板（Pod Template）_ 来替你创建 Pod 并管理它们。 +**Pod 模板（Pod Template）**来替你创建 Pod 并管理它们。 Pod 模板是包含在工作负载对象中的规范，用来创建 Pod。这类负载资源包括 [Deployment](/zh-cn/docs/concepts/workloads/controllers/deployment/)、 @@ -339,14 +334,14 @@ metadata: name: hello spec: template: - # 这里是 Pod 模版 + # 这里是 Pod 模板 spec: containers: - name: hello image: busybox:1.28 command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600'] restartPolicy: OnFailure - # 以上为 Pod 模版 + # 以上为 Pod 模板 ``` -修改 Pod 模版或者切换到新的 Pod 模版都不会对已经存在的 Pod 起作用。 -Pod 不会直接收到模版的更新。相反， -新的 Pod 会被创建出来，与更改后的 Pod 模版匹配。 +修改 Pod 模板或者切换到新的 Pod 模板都不会对已经存在的 Pod 起作用。 +Pod 不会直接收到模板的更新。相反， +新的 Pod 会被创建出来，与更改后的 Pod 模板匹配。 例如，Deployment 控制器针对每个 Deployment 对象确保运行中的 Pod 与当前的 Pod -模版匹配。如果模版被更新，则 Deployment 必须删除现有的 Pod，基于更新后的模版 -创建新的 Pod。每个工作负载资源都实现了自己的规则，用来处理对 Pod 模版的更新。 +模板匹配。如果模板被更新，则 Deployment 必须删除现有的 Pod，基于更新后的模板创建新的 Pod。 +每个工作负载资源都实现了自己的规则，用来处理对 Pod 模板的更新。 在节点上，{{< glossary_tooltip term_id="kubelet" text="kubelet" >}} 并不直接监测 -或管理与 Pod 模版相关的细节或模版的更新，这些细节都被抽象出来。 -这种抽象和关注点分离简化了整个系统的语义，并且使得用户可以在不改变现有代码的 -前提下就能扩展集群的行为。 +或管理与 Pod 模板相关的细节或模板的更新，这些细节都被抽象出来。 +这种抽象和关注点分离简化了整个系统的语义， +并且使得用户可以在不改变现有代码的前提下就能扩展集群的行为。 ## Pod 更新与替换 {#pod-update-and-replacement} -正如前面章节所述，当某工作负载的 Pod 模板被改变时，控制器会基于更新的模板 -创建新的 Pod 对象而不是对现有 Pod 执行更新或者修补操作。 +正如前面章节所述，当某工作负载的 Pod 模板被改变时， +控制器会基于更新的模板创建新的 Pod 对象而不是对现有 Pod 执行更新或者修补操作。 - Pod 的绝大多数元数据都是不可变的。例如，你不可以改变其 `namespace`、`name`、 - `uid` 或者 `creationTimestamp` 字段；`generation` 字段是比较特别的，如果更新 - 该字段，只能增加字段取值而不能减少。 + `uid` 或者 `creationTimestamp` 字段；`generation` 字段是比较特别的， + 如果更新该字段，只能增加字段取值而不能减少。 - 如果 `metadata.deletionTimestamp` 已经被设置，则不可以向 `metadata.finalizers` 列表中添加新的条目。 - Pod 更新不可以改变除 `spec.containers[*].image`、`spec.initContainers[*].image`、 @@ -478,9 +473,8 @@ they must coordinate how they use the shared network resources (such as ports). 每个 Pod 都在每个地址族中获得一个唯一的 IP 地址。 Pod 中的每个容器共享网络名字空间，包括 IP 地址和网络端口。 -*Pod 内* 的容器可以使用 `localhost` 互相通信。 -当 Pod 中的容器与 *Pod 之外* 的实体通信时，它们必须协调如何使用共享的网络资源 -（例如端口）。 +**Pod 内**的容器可以使用 `localhost` 互相通信。 +当 Pod 中的容器与 **Pod 之外**的实体通信时，它们必须协调如何使用共享的网络资源（例如端口）。 {{< note >}} -你的{{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}必须支持 -特权容器的概念才能使用这一配置。 +你的{{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}} +必须支持特权容器的概念才能使用这一配置。 {{< /note >}} ## 静态 Pod {#static-pods} -_静态 Pod（Static Pod）_ 直接由特定节点上的 `kubelet` 守护进程管理， -不需要{{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}}看到它们。 +**静态 Pod（Static Pod）**直接由特定节点上的 `kubelet` 守护进程管理， +不需要 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}}看到它们。 尽管大多数 Pod 都是通过控制面（例如，{{< glossary_tooltip text="Deployment" term_id="deployment" >}}） 来管理的，对于静态 Pod 而言，`kubelet` 直接监控每个 Pod，并在其失效时重启之。 @@ -568,8 +561,7 @@ but cannot be controlled from there. `kubelet` 自动尝试为每个静态 Pod 在 Kubernetes API 服务器上创建一个 {{< glossary_tooltip text="镜像 Pod" term_id="mirror-pod" >}}。 -这意味着在节点上运行的 Pod 在 API 服务器上是可见的，但不可以通过 API -服务器来控制。 +这意味着在节点上运行的 Pod 在 API 服务器上是可见的，但不可以通过 API 服务器来控制。 {{< note >}} -静态 Pod 的 `spec` 不能引用其他的 API 对象（例如：{{< glossary_tooltip text="ServiceAccount" term_id="service-account" >}}、{{< glossary_tooltip text="ConfigMap" term_id="configmap" >}}、{{< glossary_tooltip text="Secret" term_id="secret" >}}等）。 +静态 Pod 的 `spec` 不能引用其他的 API 对象（例如： +{{< glossary_tooltip text="ServiceAccount" term_id="service-account" >}}、 +{{< glossary_tooltip text="ConfigMap" term_id="configmap" >}}、 +{{< glossary_tooltip text="Secret" term_id="secret" >}} 等）。 {{< /note >}} ## 容器探针 {#container-probes} -_Probe_ 是由 kubelet 对容器执行的定期诊断。要执行诊断，kubelet 可以执行三种动作： +**Probe** 是由 kubelet 对容器执行的定期诊断。要执行诊断，kubelet 可以执行三种动作： - `ExecAction`（借助容器运行时执行） - `TCPSocketAction`（由 kubelet 直接检测） @@ -616,10 +611,10 @@ _Probe_ 是由 kubelet 对容器执行的定期诊断。要执行诊断，kubele object definition describes the object in detail. * [The Distributed System Toolkit: Patterns for Composite Containers](/blog/2015/06/the-distributed-system-toolkit-patterns/) explains common layouts for Pods with more than one container. --> -* 了解 [Pod 生命周期](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/) +* 了解 [Pod 生命周期](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/)。 * 了解 [RuntimeClass](/zh-cn/docs/concepts/containers/runtime-class/)，以及如何使用它 - 来配置不同的 Pod 使用不同的容器运行时配置 -* 了解 [Pod 拓扑分布约束](/zh-cn/docs/concepts/workloads/pods/pod-topology-spread-constraints/) + 来配置不同的 Pod 使用不同的容器运行时配置。 +* 了解 [Pod 拓扑分布约束](/zh-cn/docs/concepts/workloads/pods/pod-topology-spread-constraints/)。 * 了解 [PodDisruptionBudget](/zh-cn/docs/concepts/workloads/pods/disruptions/)，以及你 如何可以利用它在出现干扰因素时管理应用的可用性。 * Pod 在 Kubernetes REST API 中是一个顶层资源。 @@ -641,4 +636,3 @@ To understand the context for why Kubernetes wraps a common Pod API in other res * [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html) * [Omega](https://research.google/pubs/pub41684/) * [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/). -