Switch language name 'zh' to 'zh-cn'

This is the first step to rename 'zh' to 'zh-cn'. There are several reasons why we rename the language name. - The upstream docsy theme changed the language name, leading to many warnings during site build; The side-effect is that the i18n strings are no longer working. - We believe renaming the language is the right thing to do, because this move can make room for other variants of Chinese language, such as 'zh-tw', 'zh-sg' etc. There would be several follow-ups to this PR, such as fixing the intra-site links, adding redirects etc. We will lock up changes to zh/zh-cn pages for the moment, until this one gets in. This PR is based on commit cdad0a7342.
2022-06-10 20:25:27 +08:00
parent 3d345b1816
commit c52818c03d
1347 changed files with 8 additions and 6 deletions
@@ -0,0 +1,5 @@
+---
+title: "策略"
+weight: 90
+description: 可配置的、可应用到一组资源的策略。
+---
@@ -0,0 +1,131 @@
+---
+title: 限制范围
+content_type: concept
+weight: 10
+---
+
+<!-- overview -->
+
+<!--
+By default, containers run with unbounded [compute resources](/docs/concepts/configuration/manage-resources-containers/) on a Kubernetes cluster.
+With resource quotas, cluster administrators can restrict resource consumption and creation on a {{< glossary_tooltip text="namespace" term_id="namespace" >}} basis.
+Within a namespace, a Pod or Container can consume as much CPU and memory as defined by the namespace's resource quota. There is a concern that one Pod or Container could monopolize all available resources. A LimitRange is a policy to constrain resource allocations (to Pods or Containers) in a namespace.
+-->
+默认情况下， Kubernetes 集群上的容器运行使用的[计算资源](/zh/docs/concepts/configuration/manage-resources-containers/)没有限制。
+使用资源配额，集群管理员可以以{{< glossary_tooltip text="名字空间" term_id="namespace" >}}为单位，限制其资源的使用与创建。
+在命名空间中，一个 Pod 或 Container 最多能够使用命名空间的资源配额所定义的 CPU 和内存用量。
+有人担心，一个 Pod 或 Container 会垄断所有可用的资源。
+LimitRange 是在命名空间内限制资源分配（给多个 Pod 或 Container）的策略对象。
+
+<!-- body -->
+
+<!--
+A _LimitRange_ provides constraints that can:
+
+- Enforce minimum and maximum compute resources usage per Pod or Container in a namespace.
+- Enforce minimum and maximum storage request per PersistentVolumeClaim in a namespace.
+- Enforce a ratio between request and limit for a resource in a namespace.
+- Set default request/limit for compute resources in a namespace and automatically inject them to Containers at runtime.
+-->
+
+一个 _LimitRange（限制范围）_ 对象提供的限制能够做到：
+
+- 在一个命名空间中实施对每个 Pod 或 Container 最小和最大的资源使用量的限制。
+- 在一个命名空间中实施对每个 PersistentVolumeClaim 能申请的最小和最大的存储空间大小的限制。
+- 在一个命名空间中实施对一种资源的申请值和限制值的比值的控制。
+- 设置一个命名空间中对计算资源的默认申请/限制值，并且自动的在运行时注入到多个 Container 中。
+
+<!--
+## Enabling LimitRange
+
+LimitRange support has been enabled by default since Kubernetes 1.10.
+
+LimitRange support is enabled by default for many Kubernetes distributions.
+-->
+## 启用 LimitRange
+
+对 LimitRange 的支持自 Kubernetes 1.10 版本默认启用。
+
+LimitRange 支持在很多 Kubernetes 发行版本中也是默认启用的。
+
+<!--
+The name of a LimitRange object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+-->
+LimitRange 的名称必须是合法的
+[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
+
+<!--
+### Overview of Limit Range
+
+- The administrator creates one `LimitRange` in one namespace.
+- Users create resources like Pods, Containers, and PersistentVolumeClaims in the namespace.
+- The `LimitRanger` admission controller enforces defaults and limits for all Pods and Containers that do not set compute resource requirements and tracks usage to ensure it does not exceed resource minimum, maximum and ratio defined in any LimitRange present in the namespace.
+- If creating or updating a resource (Pod, Container, PersistentVolumeClaim) that violates a LimitRange constraint, the request to the API server will fail with an HTTP status code `403 FORBIDDEN` and a message explaining the constraint that have been violated.
+- If a LimitRange is activated in a namespace for compute resources like `cpu` and `memory`, users must specify
+  requests or limits for those values. Otherwise, the system may reject Pod creation.
+- LimitRange validations occurs only at Pod Admission stage, not on Running Pods.
+-->
+### 限制范围总览
+
+- 管理员在一个命名空间内创建一个 `LimitRange` 对象。
+- 用户在命名空间内创建 Pod ，Container 和 PersistentVolumeClaim 等资源。
+- `LimitRanger` 准入控制器对所有没有设置计算资源需求的 Pod 和 Container 设置默认值与限制值，
+  并跟踪其使用量以保证没有超出命名空间中存在的任意 LimitRange 对象中的最小、最大资源使用量以及使用量比值。
+- 若创建或更新资源（Pod、 Container、PersistentVolumeClaim）违反了 LimitRange 的约束，
+  向 API 服务器的请求会失败，并返回 HTTP 状态码 `403 FORBIDDEN` 与描述哪一项约束被违反的消息。
+- 若命名空间中的 LimitRange 启用了对 `cpu` 和 `memory` 的限制，
+  用户必须指定这些值的需求使用量与限制使用量。否则，系统将会拒绝创建 Pod。
+- LimitRange 的验证仅在 Pod 准入阶段进行，不对正在运行的 Pod 进行验证。
+
+<!--
+Examples of policies that could be created using limit range are:
+
+- In a 2 node cluster with a capacity of 8 GiB RAM and 16 cores, constrain Pods in a namespace to request 100m of CPU with a max limit of 500m for CPU and request 200Mi for Memory with a max limit of 600Mi for Memory.
+- Define default CPU limit and request to 150m and memory default request to 300Mi for Containers started with no cpu and memory requests in their specs.
+-->
+能够使用限制范围创建的策略示例有：
+
+- 在一个有两个节点，8 GiB 内存与16个核的集群中，限制一个命名空间的 Pod 申请
+  100m 单位，最大 500m 单位的 CPU，以及申请 200Mi，最大 600Mi 的内存。
+- 为 spec 中没有 cpu 和内存需求值的 Container 定义默认 CPU 限制值与需求值
+  150m，内存默认需求值 300Mi。
+
+<!--
+In the case where the total limits of the namespace is less than the sum of the limits of the Pods/Containers,
+there may be contention for resources. In this case, the Containers or Pods will not be created.
+-->
+在命名空间的总限制值小于 Pod 或 Container 的限制值的总和的情况下，可能会产生资源竞争。
+在这种情况下，将不会创建 Container 或 Pod。
+
+<!--
+Neither contention nor changes to a LimitRange will affect already created resources.
+-->
+竞争和对 LimitRange 的改变都不会影响任何已经创建了的资源。
+
+## {{% heading "whatsnext" %}}
+
+<!--
+See [LimitRanger design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) for more information.
+-->
+参阅 [LimitRanger 设计文档](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md)获取更多信息。
+
+<!--
+For examples on using limits, see:
+
+- See [how to configure minimum and maximum CPU constraints per namespace](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/).
+- See [how to configure minimum and maximum Memory constraints per namespace](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/).
+- See [how to configure default CPU Requests and Limits per namespace](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/).
+- See [how to configure default Memory Requests and Limits per namespace](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/).
+- Check [how to configure minimum and maximum Storage consumption per namespace](/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage).
+- See a [detailed example on configuring quota per namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/).
+-->
+关于使用限值的例子，可参看
+
+- [如何配置每个命名空间最小和最大的 CPU 约束](/zh/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)。
+- [如何配置每个命名空间最小和最大的内存约束](/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)。
+- [如何配置每个命名空间默认的 CPU 申请值和限制值](/zh/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)。
+- [如何配置每个命名空间默认的内存申请值和限制值](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)。
+- [如何配置每个命名空间最小和最大存储使用量](/zh/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage)。
+- [配置每个命名空间的配额的详细例子](/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)。
+
@@ -0,0 +1,45 @@
+---
+title: 节点资源管理器
+content_type: concept
+weight: 50
+---
+<!-- 
+---
+reviewers:
+- derekwaynecarr
+- klueska
+title: Node Resource Managers 
+content_type: concept
+weight: 50
+---
+-->
+
+<!-- overview -->
+
+<!-- 
+In order to support latency-critical and high-throughput workloads, Kubernetes offers a suite of Resource Managers. The managers aim to co-ordinate and optimise node's resources alignment for pods configured with a specific requirement for CPUs, devices, and memory (hugepages) resources. 
+-->
+Kubernetes 提供了一组资源管理器，用于支持延迟敏感的、高吞吐量的工作负载。
+资源管理器的目标是协调和优化节点资源，以支持对 CPU、设备和内存（巨页）等资源有特殊需求的 Pod。
+
+<!-- body -->
+
+<!-- 
+The main manager, the Topology Manager, is a Kubelet component that co-ordinates the overall resource management process through its [policy](/docs/tasks/administer-cluster/topology-manager/).
+
+The configuration of individual managers is elaborated in dedicated documents:
+-->
+主管理器，也叫拓扑管理器（Topology Manager），是一个 Kubelet 组件，
+它通过[策略](/zh/docs/tasks/administer-cluster/topology-manager/)，
+协调全局的资源管理过程。
+
+各个管理器的配置方式会在专项文档中详细阐述：
+
+<!-- 
+- [CPU Manager Policies](/docs/tasks/administer-cluster/cpu-management-policies/)
+- [Device Manager](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager)
+- [Memory Manager Policies](/docs/tasks/administer-cluster/memory-manager/)
+-->
+- [CPU 管理器策略](/zh/docs/tasks/administer-cluster/cpu-management-policies/)
+- [设备管理器](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager)
+- [内存管理器策略](/zh/docs/tasks/administer-cluster/memory-manager/)
@@ -0,0 +1,238 @@
+---
+title: 进程 ID 约束与预留
+content_type: concept
+weight: 40
+---
+
+<!--
+reviewers:
+- derekwaynecarr
+title: Process ID Limits And Reservations
+content_type: concept
+weight: 40
+-->
+
+<!-- overview -->
+
+{{< feature-state for_k8s_version="v1.20" state="stable" >}}
+
+<!--
+Kubernetes allow you to limit the number of process IDs (PIDs) that a
+{{< glossary_tooltip term_id="Pod" text="Pod" >}} can use.
+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）使用。
+
+<!-- body -->
+
+<!--
+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）是节点上的一种基础资源。很容易就会在尚未超出其它资源约束的时候就
+已经触及任务个数上限，进而导致宿主机器不稳定。
+
+<!--
+Cluster administrators require mechanisms to ensure that Pods running in the
+cluster cannot induce PID exhaustion that prevents host daemons (such as the
+{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} or
+{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}},
+and potentially also the container runtime) from running.
+In addition, it is important to ensure that PIDs are limited among Pods in order
+to ensure they have limited impact on other workloads on the same node.
+-->
+集群管理员需要一定的机制来确保集群中运行的 Pod 不会导致 PID 资源枯竭，甚而
+造成宿主机上的守护进程（例如
+{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} 或者
+{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}
+乃至包括容器运行时本身）无法正常运行。
+此外，确保 Pod 中 PID 的个数受限对于保证其不会影响到同一节点上其它负载也很重要。
+
+{{< note >}}
+<!--
+On certain Linux installations, the operating system sets the PIDs limit to a low default,
+such as `32768`. Consider raising the value of `/proc/sys/kernel/pid_max`.
+-->
+在某些 Linux 安装环境中，操作系统会将 PID 约束设置为一个较低的默认值，例如
+`32768`。这时可以考虑提升 `/proc/sys/kernel/pid_max` 的设置值。
+{{< /note >}}
+
+<!--
+You can configure a kubelet to limit the number of PIDs a given Pod can consume.
+For example, if your node's host OS is set to use a maximum of `262144` PIDs and
+expect to host less than `250` Pods, one can give each Pod a budget of `1000`
+PIDs to prevent using up that node's overall number of available PIDs. If the
+admin wants to overcommit PIDs similar to CPU or memory, they may do so as well
+with some additional risks. Either way, a single Pod will not be able to bring
+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
+的预算，避免耗尽该节点上可用 PID 的总量。
+如果管理员系统像 CPU 或内存那样允许对 PID 进行过量分配（Overcommit），他们也可以
+这样做，只是会有一些额外的风险。不管怎样，任何一个 Pod 都不可以将整个机器的运行
+状态破坏。这类资源限制有助于避免简单的派生炸弹（Fork
+Bomb）影响到整个集群的运行。
+
+<!--
+Per-Pod PID limiting allows administrators to protect one Pod from another, but
+does not ensure that all Pods scheduled onto that host are unable to impact the node overall.
+Per-Pod limiting also does not protect the node agents themselves from PID exhaustion.
+
+You can also reserve an amount of PIDs for node overhead, separate from the
+allocation to Pods. This is similar to how you can reserve CPU, memory, or other
+resources for use by the operating system and other facilities outside of Pods
+and their containers.
+-->
+在 Pod 级别设置 PID 限制使得管理员能够保护 Pod 之间不会互相伤害，不过无法
+确保所有调度到该宿主机器上的所有 Pod 都不会影响到节点整体。
+Pod 级别的限制也无法保护节点代理任务自身不会受到 PID 耗尽的影响。
+
+你也可以预留一定量的 PID，作为节点的额外开销，与分配给 Pod 的 PID 集合独立。
+这有点类似于在给操作系统和其它设施预留 CPU、内存或其它资源时所做的操作，
+这些任务都在 Pod 及其所包含的容器之外运行。
+
+<!--
+PID limiting is a an important sibling to [compute
+resource](/docs/concepts/configuration/manage-resources-containers/) requests
+and limits. However, you specify it in a different way: rather than defining a
+Pod's resource limit in the `.spec` for a Pod, you configure the limit as a
+setting on the kubelet. Pod-defined PID limits are not currently supported.
+-->
+PID 限制是与[计算资源](/zh/docs/concepts/configuration/manage-resources-containers/)
+请求和限制相辅相成的一种机制。不过，你需要用一种不同的方式来设置这一限制：
+你需要将其设置到 kubelet 上而不是在 Pod 的 `.spec` 中为 Pod 设置资源限制。
+目前还不支持在 Pod 级别设置 PID 限制。
+
+
+{{< caution >}}
+<!--
+This means that the limit that applies to a Pod may be different depending on
+where the Pod is scheduled. To make things simple, it's easiest if all Nodes use
+the same PID resource limits and reservations.
+-->
+这意味着，施加在 Pod 之上的限制值可能因为 Pod 运行所在的节点不同而有差别。
+为了简化系统，最简单的方法是为所有节点设置相同的 PID 资源限制和预留值。
+{{< /caution >}}
+
+<!--
+## Node PID limits
+
+Kubernetes allows you to reserve a number of process IDs for the system use. To
+configure the reservation, use the parameter `pid=<number>` in the
+`--system-reserved` and `--kube-reserved` command line options to the kubelet.
+The value you specified declares that the specified number of process IDs will
+be reserved for the system as a whole and for Kubernetes system daemons
+respectively.
+-->
+## 节点级别 PID 限制   {#node-pid-limits}
+
+Kubernetes 允许你为系统预留一定量的进程 ID。为了配置预留数量，你可以使用
+kubelet 的 `--system-reserved` 和 `--kube-reserved` 命令行选项中的参数
+`pid=<number>`。你所设置的参数值分别用来声明为整个系统和 Kubernetes 系统
+守护进程所保留的进程 ID 数目。
+
+{{< note >}}
+<!--
+Before Kubernetes version 1.20, PID resource limiting with Node-level
+reservations required enabling the [feature
+gate](/docs/reference/command-line-tools-reference/feature-gates/)
+`SupportNodePidsLimit` to work.
+-->
+在 Kubernetes 1.20 版本之前，在节点级别通过 PID 资源限制预留 PID 的能力
+需要启用[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
+`SupportNodePidsLimit` 才行。
+{{< /note >}}
+
+<!--
+## Pod PID limits
+
+Kubernetes allows you to limit the number of processes running in a Pod. You
+specify this limit at the node level, rather than configuring it as a resource
+limit for a particular Pod. Each Node can have a different PID limit.  
+To configure the limit, you can specify the command line parameter `--pod-max-pids`
+to the kubelet, or set `PodPidsLimit` in the kubelet
+[configuration file](/docs/tasks/administer-cluster/kubelet-config-file/).
+-->
+## Pod 级别 PID 限制   {#pod-pid-limits}
+
+Kubernetes 允许你限制 Pod 中运行的进程个数。你可以在节点级别设置这一限制，
+而不是为特定的 Pod 来将其设置为资源限制。
+每个节点都可以有不同的 PID 限制设置。
+要设置限制值，你可以设置 kubelet 的命令行参数 `--pod-max-pids`，或者
+在 kubelet 的[配置文件](/zh/docs/tasks/administer-cluster/kubelet-config-file/)
+中设置 `PodPidsLimit`。
+
+{{< note >}}
+<!--
+Before Kubernetes version 1.20, PID resource limiting for Pods required enabling
+the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
+`SupportPodPidsLimit` to work.
+-->
+在 Kubernetes 1.20 版本之前，为 Pod 设置 PID 资源限制的能力需要启用
+[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
+`SupportNodePidsLimit` 才行。
+{{< /note >}}
+
+<!--
+## PID based eviction
+
+You can configure kubelet to start terminating a Pod when it is misbehaving and consuming abnormal amount of resources.
+This feature is called eviction. You can
+[Configure Out of Resource Handling](/docs/concepts/scheduling-eviction/node-pressure-eviction/)
+for various eviction signals.
+Use `pid.available` eviction signal to configure the threshold for number of PIDs used by Pod.
+You can set soft and hard eviction policies.
+However, even with the hard eviction policy, if the number of PIDs growing very fast,
+node can still get into unstable state by hitting the node PIDs limit.
+Eviction signal value is calculated periodically and does NOT enforce the limit.
+-->
+## 基于 PID 的驱逐    {#pid-based-eviction}
+
+你可以配置 kubelet 使之在 Pod 行为不正常或者消耗不正常数量资源的时候将其终止。
+这一特性称作驱逐。你可以针对不同的驱逐信号
+[配置资源不足的处理](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/)。
+使用 `pid.available` 驱逐信号来配置 Pod 使用的 PID 个数的阈值。
+你可以设置硬性的和软性的驱逐策略。不过，即使使用硬性的驱逐策略，
+如果 PID 个数增长过快，节点仍然可能因为触及节点 PID 限制而进入一种不稳定状态。
+驱逐信号的取值是周期性计算的，而不是一直能够强制实施约束。
+
+<!--
+PID limiting - per Pod and per Node sets the hard limit.
+Once the limit is hit, workload will start experiencing failures when trying to get a new PID.
+It may or may not lead to rescheduling of a Pod,
+depending on how workload reacts on these failures and how liveleness and readiness
+probes are configured for the Pod. However, if limits were set correctly,
+you can guarantee that other Pods workload and system processes will not run out of PIDs
+when one Pod is misbehaving.
+-->
+Pod 级别和节点级别的 PID 限制会设置硬性限制。
+一旦触及限制值，工作负载会在尝试获得新的 PID 时开始遇到问题。
+这可能会也可能不会导致 Pod 被重新调度，取决于工作负载如何应对这类失败
+以及 Pod 的存活性和就绪态探测是如何配置的。
+可是，如果限制值被正确设置，你可以确保其它 Pod 负载和系统进程不会因为某个
+Pod 行为不正常而没有 PID 可用。
+
+## {{% heading "whatsnext" %}}
+
+<!--
+- Refer to the [PID Limiting enhancement document](https://github.com/kubernetes/enhancements/blob/097b4d8276bc9564e56adf72505d43ce9bc5e9e8/keps/sig-node/20190129-pid-limiting.md) for more information.
+- For historical context, read
+  [Process ID Limiting for Stability Improvements in Kubernetes 1.14](/blog/2019/04/15/process-id-limiting-for-stability-improvements-in-kubernetes-1.14/).
+- Read [Managing Resources for Containers](/docs/concepts/configuration/manage-resources-containers/).
+- Learn how to [Configure Out of Resource Handling](/docs/concepts/scheduling-eviction/node-pressure-eviction/).
+-->
+- 参阅 [PID 约束改进文档](https://github.com/kubernetes/enhancements/blob/097b4d8276bc9564e56adf72505d43ce9bc5e9e8/keps/sig-node/20190129-pid-limiting.md)
+  以了解更多信息。
+- 关于历史背景，请阅读
+  [Kubernetes 1.14 中限制进程 ID 以提升稳定性](/blog/2019/04/15/process-id-limiting-for-stability-improvements-in-kubernetes-1.14/)
+  的博文。
+- 请阅读[为容器管理资源](/zh/docs/concepts/configuration/manage-resources-containers/)。
+- 学习如何[配置资源不足情况的处理](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/)。
+