diff --git a/content/zh-cn/docs/concepts/policy/pid-limiting.md b/content/zh-cn/docs/concepts/policy/pid-limiting.md index 61fed9674b..4faac45cc0 100644 --- a/content/zh-cn/docs/concepts/policy/pid-limiting.md +++ b/content/zh-cn/docs/concepts/policy/pid-limiting.md @@ -22,9 +22,10 @@ Kubernetes allow you to limit the number of process IDs (PIDs) that a You can also reserve a number of allocatable PIDs for each {{< glossary_tooltip term_id="node" text="node" >}} for use by the operating system and daemons (rather than by Pods). --> -Kubernetes 允许你限制一个 {{< glossary_tooltip term_id="Pod" text="Pod" >}} 中可以使用的 -进程 ID（PID）数目。你也可以为每个 {{< glossary_tooltip term_id="node" text="节点" >}} -预留一定数量的可分配的 PID，供操作系统和守护进程（而非 Pod）使用。 +Kubernetes 允许你限制一个 {{< glossary_tooltip term_id="Pod" text="Pod" >}} +中可以使用的进程 ID（PID）数目。 +你也可以为每个{{< glossary_tooltip term_id="node" text="节点" >}}预留一定数量的可分配的 PID， +供操作系统和守护进程（而非 Pod）使用。 @@ -33,8 +34,8 @@ Process IDs (PIDs) are a fundamental resource on nodes. It is trivial to hit the task limit without hitting any other resource limits, which can then cause instability to a host machine. --> -进程 ID（PID）是节点上的一种基础资源。很容易就会在尚未超出其它资源约束的时候就 -已经触及任务个数上限，进而导致宿主机器不稳定。 +进程 ID（PID）是节点上的一种基础资源。很容易就会在尚未超出其它资源约束的时候就已经触及任务个数上限， +进而导致宿主机器不稳定。 -集群管理员需要一定的机制来确保集群中运行的 Pod 不会导致 PID 资源枯竭，甚而 -造成宿主机上的守护进程（例如 +集群管理员需要一定的机制来确保集群中运行的 Pod 不会导致 PID 资源枯竭， +甚而造成宿主机上的守护进程（例如 {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} 或者 {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}} 乃至包括容器运行时本身）无法正常运行。 @@ -72,13 +73,12 @@ the whole machine down. This kind of resource limiting helps to prevent simple fork bombs from affecting operation of an entire cluster. --> 你可以配置 kubelet 限制给定 Pod 能够使用的 PID 个数。 -例如，如果你的节点上的宿主操作系统被设置为最多可使用 `262144` 个 PID，同时预期 -节点上会运行的 Pod 个数不会超过 `250`，那么你可以为每个 Pod 设置 `1000` 个 PID +例如，如果你的节点上的宿主操作系统被设置为最多可使用 `262144` 个 PID， +同时预期节点上会运行的 Pod 个数不会超过 `250`，那么你可以为每个 Pod 设置 `1000` 个 PID 的预算，避免耗尽该节点上可用 PID 的总量。 -如果管理员系统像 CPU 或内存那样允许对 PID 进行过量分配（Overcommit），他们也可以 -这样做，只是会有一些额外的风险。不管怎样，任何一个 Pod 都不可以将整个机器的运行 -状态破坏。这类资源限制有助于避免简单的派生炸弹（Fork -Bomb）影响到整个集群的运行。 +如果管理员系统像 CPU 或内存那样允许对 PID 进行过量分配（Overcommit），他们也可以这样做， +只是会有一些额外的风险。不管怎样，任何一个 Pod 都不可以将整个机器的运行状态破坏。 +这类资源限制有助于避免简单的派生炸弹（Fork Bomb）影响到整个集群的运行。 -在 Pod 级别设置 PID 限制使得管理员能够保护 Pod 之间不会互相伤害，不过无法 -确保所有调度到该宿主机器上的所有 Pod 都不会影响到节点整体。 +在 Pod 级别设置 PID 限制使得管理员能够保护 Pod 之间不会互相伤害， +不过无法确保所有调度到该宿主机器上的所有 Pod 都不会影响到节点整体。 Pod 级别的限制也无法保护节点代理任务自身不会受到 PID 耗尽的影响。 你也可以预留一定量的 PID，作为节点的额外开销，与分配给 Pod 的 PID 集合独立。 @@ -110,7 +110,6 @@ PID 限制是与[计算资源](/zh-cn/docs/concepts/configuration/manage-resourc 你需要将其设置到 kubelet 上而不是在 Pod 的 `.spec` 中为 Pod 设置资源限制。 目前还不支持在 Pod 级别设置 PID 限制。 - {{< caution >}} -在 Kubernetes 1.20 版本之前，在节点级别通过 PID 资源限制预留 PID 的能力 -需要启用[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) -`SupportNodePidsLimit` 才行。 -{{< /note >}} +`pid=`。你所设置的参数值分别用来声明为整个系统和 Kubernetes +系统守护进程所保留的进程 ID 数目。 -在 Kubernetes 1.20 版本之前，为 Pod 设置 PID 资源限制的能力需要启用 -[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) -`SupportNodePidsLimit` 才行。 -{{< /note >}} +而不是为特定的 Pod 来将其设置为资源限制。每个节点都可以有不同的 PID 限制设置。 +要设置限制值，你可以设置 kubelet 的命令行参数 `--pod-max-pids`，或者在 kubelet +的[配置文件](/zh-cn/docs/tasks/administer-cluster/kubelet-config-file/)中设置 +`PodPidsLimit`。 ## 基于 PID 的驱逐 {#pid-based-eviction} -你可以配置 kubelet 使之在 Pod 行为不正常或者消耗不正常数量资源的时候将其终止。 -这一特性称作驱逐。你可以针对不同的驱逐信号 -[配置资源不足的处理](/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/)。 +你可以配置 kubelet 使之在 Pod 行为不正常或者消耗不正常数量资源的时候将其终止。这一特性称作驱逐。 +你可以针对不同的驱逐信号[配置资源不足的处理](/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/)。 使用 `pid.available` 驱逐信号来配置 Pod 使用的 PID 个数的阈值。 你可以设置硬性的和软性的驱逐策略。不过，即使使用硬性的驱逐策略， 如果 PID 个数增长过快，节点仍然可能因为触及节点 PID 限制而进入一种不稳定状态。 @@ -214,8 +188,8 @@ when one Pod is misbehaving. --> Pod 级别和节点级别的 PID 限制会设置硬性限制。 一旦触及限制值，工作负载会在尝试获得新的 PID 时开始遇到问题。 -这可能会也可能不会导致 Pod 被重新调度，取决于工作负载如何应对这类失败 -以及 Pod 的存活性和就绪态探测是如何配置的。 +这可能会也可能不会导致 Pod 被重新调度，取决于工作负载如何应对这类失败以及 +Pod 的存活性和就绪态探测是如何配置的。 可是，如果限制值被正确设置，你可以确保其它 Pod 负载和系统进程不会因为某个 Pod 行为不正常而没有 PID 可用。