From 210775f69164f98789c818ee6c2432c4deb42493 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Wed, 28 Apr 2021 11:27:08 +0800 Subject: [PATCH] [zh] Resync concepts section (7) --- .../concepts/workloads/pods/disruptions.md | 26 ++++--- .../workloads/pods/ephemeral-containers.md | 71 +++++++------------ .../workloads/pods/init-containers.md | 18 ++--- .../concepts/workloads/pods/pod-lifecycle.md | 41 ++++++----- .../pods/pod-topology-spread-constraints.md | 5 +- 5 files changed, 72 insertions(+), 89 deletions(-) diff --git a/content/zh/docs/concepts/workloads/pods/disruptions.md b/content/zh/docs/concepts/workloads/pods/disruptions.md index 442ab1bc4b..7320859778 100644 --- a/content/zh/docs/concepts/workloads/pods/disruptions.md +++ b/content/zh/docs/concepts/workloads/pods/disruptions.md @@ -5,6 +5,10 @@ weight: 60 --- - 确保 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/setup/best-practices/multiple-zones/)）扩展应用程序。 + [反亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) + 或跨区域（如果使用[多区域集群](/zh/docs/setup/best-practices/multiple-zones/)）扩展应用程序。 -## 干扰预算 +## 干扰预算 {#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 前端可能希望确保提供负载的副本数量永远不会低于总数 -集群管理员和托管提供商应该使用遵循 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)，期间会 diff --git a/content/zh/docs/concepts/workloads/pods/ephemeral-containers.md b/content/zh/docs/concepts/workloads/pods/ephemeral-containers.md index 7161e3f7f3..728500be34 100644 --- a/content/zh/docs/concepts/workloads/pods/ephemeral-containers.md +++ b/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 >}} -{{< warning >}} -临时容器处于早期的 alpha 阶段，不适用于生产环境集群。 +临时容器处于早期的 Alpha 阶段，不适用于生产环境集群。 应该预料到临时容器在某些情况下不起作用，例如在定位容器的命名空间时。 根据 [Kubernetes 弃用政策](/zh/docs/reference/using-api/deprecation-policy/)， -此 alpha 功能将来可能发生重大变化或被完全删除。 +此 Alpha 功能将来可能发生重大变化或被完全删除。 {{< /warning >}} @@ -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/) 很有帮助，可以查看其他容器中的进程。 +关于如何使用临时容器来执行故障排查的例子，可参阅 +[使用临时调试容器来调试](/zh/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)。 + +### 临时容器 API {#ephemeral-containers-api}」 + +{{< note >}} + -### 示例 - -{{< 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 ``` - -如果启用了进程命名空间共享，则可以查看该 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 -``` - diff --git a/content/zh/docs/concepts/workloads/pods/init-containers.md b/content/zh/docs/concepts/workloads/pods/init-containers.md index 692928099b..283b9f3759 100644 --- a/content/zh/docs/concepts/workloads/pods/init-containers.md +++ b/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 容器的完成记录将会丢失。 + +当 Init 容器的镜像发生改变或者 Init 容器的完成记录因为垃圾收集等原因被丢失时， +Pod 不会被重启。这一行为适用于 Kubernetes v1.20 及更新版本。如果你在使用较早 +版本的 Kubernetes，可查阅你所使用的版本对应的文档。 + ## {{% heading "whatsnext" %}} Pod 自身不具有自愈能力。如果 Pod 被调度到某{{< glossary_tooltip text="节点" term_id="node" >}} -而该节点之后失效，或者调度操作本身失效，Pod 会被删除；与此类似，Pod 无法在节点资源 -耗尽或者节点维护期间继续存活。Kubernetes 使用一种高级抽象，称作 -{{< glossary_tooltip term_id="controller" text="控制器" >}}，来管理这些相对而言 -可随时丢弃的 Pod 实例。 +而该节点之后失效，Pod 会被删除；类似地，Pod 无法在因节点资源 +耗尽或者节点维护而被驱逐期间继续存活。Kubernetes 使用一种高级抽象 +来管理这些相对而言可随时丢弃的 Pod 实例，称作 +{{< glossary_tooltip term_id="controller" text="控制器" >}}。 -{{< 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. 如果 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/)。 diff --git a/content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index c18ed5c85d..2ddc5a4d9d 100644 --- a/content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md +++ b/content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -95,10 +95,11 @@ graph TB {{< /mermaid >}} 你可以复用在大多数集群上自动创建和填充的 -[常用标签](/zh/docs/reference/kubernetes-api/labels-annotations-taints/)， +[常用标签](/zh/docs/reference/labels-annotations-taints/)， 而不是手动添加标签。