kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge pull request #23198 from tengqm/zh-links-tasks-7 

[zh] Tidy up and fix links in tasks section (7/10)
pull/23351/head
Kubernetes Prow Robot 2020-08-22 20:49:42 -07:00 committed by GitHub
parent 0355f57f05 30423d108f
commit d195b0f580
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
12 changed files with 724 additions and 795 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

141
content/zh/docs/tasks/administer-cluster/cpu-management-policies.md
View File

@ -1,20 +1,15 @@
---
title: 控制节点上的 CPU 管理策略
reviewers:
- sjenning
- ConnorDoyle
- balajismaniam
content_type: task
---
<!--
title: Control CPU Management Policies on the Node
reviewers:
- sjenning
- ConnorDoyle
- balajismaniam
content_type: task
--->
-->
<!-- overview -->
@ -27,19 +22,15 @@ stronger guarantees in terms of latency and/or performance in order to operate
acceptably. The kubelet provides methods to enable more complex workload
placement policies while keeping the abstraction free from explicit placement
directives.
--->
按照设计，Kubernetes 对 pod 执行相关的很多方面进行了抽象，使得用户不必关心。然
而，为了正常运行，有些工作负载要求在延迟和/或性能方面有更强的保证。 为此，kubelet 提供方法来实现更复杂的负载放置策略，同时保持抽象，避免显式的放置指令。
-->
按照设计，Kubernetes 对 pod 执行相关的很多方面进行了抽象，使得用户不必关心。
然而，为了正常运行，有些工作负载要求在延迟和/或性能方面有更强的保证。
为此，kubelet 提供方法来实现更复杂的负载放置策略，同时保持抽象，避免显式的放置指令。
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- steps -->
<!--
@ -51,38 +42,38 @@ the workload can move to different CPU cores depending on
whether the pod is throttled and which CPU cores are available at
scheduling time.  Many workloads are not sensitive to this migration and thus
work fine without any intervention.
--->
-->
## CPU 管理策略
默认情况下，kubelet 使用 [CFS 配额](https://en.wikipedia.org/wiki/Completely_Fair_Scheduler) 来执行 pod 的 CPU 约束。当节点上运行了很多 CPU 密集的 pod 时，工作负载可能会迁移到不同的 CPU 核，这取决于调度时 pod 是否被扼制，以及哪些 CPU 核是可用的。许多工作负载对这种迁移不敏感，因此无需任何干预即可正常工作。
默认情况下，kubelet 使用 [CFS 配额](https://en.wikipedia.org/wiki/Completely_Fair_Scheduler)
来执行 Pod 的 CPU 约束。
当节点上运行了很多 CPU 密集的 Pod 时，工作负载可能会迁移到不同的 CPU 核，
这取决于调度时 Pod 是否被扼制，以及哪些 CPU 核是可用的。
许多工作负载对这种迁移不敏感，因此无需任何干预即可正常工作。
<!--
However, in workloads where CPU cache affinity and scheduling latency
significantly affect workload performance, the kubelet allows alternative CPU
management policies to determine some placement preferences on the node.
--->
然而，有些工作负载的性能明显地受到 CPU 缓存亲和性以及调度延迟的影响，对此，kubelet 提供了可选的 CPU 管理策略，来确定节点上的一些分配偏好。
-->
然而，有些工作负载的性能明显地受到 CPU 缓存亲和性以及调度延迟的影响。
对此，kubelet 提供了可选的 CPU 管理策略，来确定节点上的一些分配偏好。
<!--
### Configuration
The CPU Manager is an alpha feature in Kubernetes v1.8. It was enabled by
default as a beta feature since v1.10.
The CPU Manager policy is set with the `--cpu-manager-policy` kubelet
The CPU Manager policy is set with the `-cpu-manager-policy` kubelet
option. There are two supported policies:
--->
-->
### 配置
CPU 管理器（CPU Manager）作为 alpha 特性引入 Kubernetes 1.8 版本。从 1.10 版本开始，作为 beta 特性默认开启。
CPU 管理策略通过 kubelet 参数 `--cpu-manager-policy` 来指定。支持两种策略：
<!--
* `none`: the default, which represents the existing scheduling behavior.
* `static`: allows pods with certain resource characteristics to be
granted increased CPU affinity and exclusivity on the node.
--->
-->
* `none`: 默认策略，表示现有的调度行为。
* `static`: 允许为节点上具有某些资源特征的 pod 赋予增强的 CPU 亲和性和独占性。
@ -90,10 +81,12 @@ CPU 管理策略通过 kubelet 参数 `--cpu-manager-policy` 来指定。支持
The CPU manager periodically writes resource updates through the CRI in
order to reconcile in-memory CPU assignments with cgroupfs. The reconcile
frequency is set through a new Kubelet configuration value
`--cpu-manager-reconcile-period`. If not specified, it defaults to the same
duration as `--node-status-update-frequency`.
--->
CPU 管理器定期通过 CRI 写入资源更新，以保证内存中 CPU 分配与 cgroupfs 一致。同步频率通过新增的 Kubelet 配置参数 `--cpu-manager-reconcile-period` 来设置。 如果不指定，默认与 `--node-status-update-frequency` 的周期相同。
`-cpu-manager-reconcile-period`. If not specified, it defaults to the same
duration as `-node-status-update-frequency`.
-->
CPU 管理器定期通过 CRI 写入资源更新，以保证内存中 CPU 分配与 cgroupfs 一致。
同步频率通过新增的 Kubelet 配置参数 `--cpu-manager-reconcile-period` 来设置。
如果不指定，默认与 `--node-status-update-frequency` 的周期相同。
<!--
### None policy
@ -103,10 +96,12 @@ affinity scheme, providing no affinity beyond what the OS scheduler does
automatically.  Limits on CPU usage for
[Guaranteed pods](/docs/tasks/configure-pod-container/quality-service-pod/)
are enforced using CFS quota.
--->
### None 策略
-->
### none 策略
`none` 策略显式地启用现有的默认 CPU 亲和方案，不提供操作系统调度器默认行为之外的亲和性策略。 通过 CFS 配额来实现 [Guaranteed pods](/docs/tasks/configure-pod-container/quality-service-pod/) 的 CPU 使用限制。
`none` 策略显式地启用现有的默认 CPU 亲和方案，不提供操作系统调度器默认行为之外的亲和性策略。
通过 CFS 配额来实现 [Guaranteed pods](/zh/docs/tasks/configure-pod-container/quality-service-pod/)
的 CPU 使用限制。
<!--
### Static policy
@ -114,40 +109,30 @@ are enforced using CFS quota.
The `static` policy allows containers in `Guaranteed` pods with integer CPU
`requests` access to exclusive CPUs on the node. This exclusivity is enforced
using the [cpuset cgroup controller](https://www.kernel.org/doc/Documentation/cgroup-v1/cpusets.txt).
--->
### Static 策略
-->
### static 策略
`static` 策略针对具有整数型 CPU `requests` 的 `Guaranteed` pod ，它允许该类 pod 中的容器访问节点上的独占 CPU 资源。这种独占性是使用 [cpuset cgroup 控制器](https://www.kernel.org/doc/Documentation/cgroup-v1/cpusets.txt) 来实现的。
`static` 策略针对具有整数型 CPU `requests` 的 `Guaranteed` Pod ，它允许该类 Pod
中的容器访问节点上的独占 CPU 资源。这种独占性是使用
[cpuset cgroup 控制器](https://www.kernel.org/doc/Documentation/cgroup-v1/cpusets.txt) 来实现的。
<!--
{{< note >}}
System services such as the container runtime and the kubelet itself can continue to run on these exclusive CPUs.  The exclusivity only extends to other pods.
{{< /note >}}
--->
-->
{{< note >}}
诸如容器运行时和 kubelet 本身的系统服务可以继续在这些独占 CPU 上运行。独占性仅针对其他 pod。
诸如容器运行时和 kubelet 本身的系统服务可以继续在这些独占 CPU 上运行。独占性仅针对其他 Pod。
{{< /note >}}
<!--
{{< note >}}
The alpha version of this policy does not guarantee static
exclusive allocations across Kubelet restarts.
{{< /note >}}
--->
{{< note >}}
该策略的 alpha 版本不保证 Kubelet 重启前后的静态独占性分配。
{{< /note >}}
<!--
{{< note >}}
CPU Manager doesn't support offlining and onlining of
CPUs at runtime. Also, if the set of online CPUs changes on the node,
the node must be drained and CPU manager manually reset by deleting the
state file `cpu_manager_state` in the kubelet root directory.
{{< /note >}}
--->
-->
{{< note >}}
CPU 管理器不支持运行时下线和上线 CPUs。此外，如果节点上的在线 CPUs 集合发生变化，则必须驱逐节点上的 pods，并通过删除 kubelet 根目录中的状态文件 `cpu_manager_state` 来手动重置 CPU 管理器。
CPU 管理器不支持运行时下线和上线 CPUs。此外，如果节点上的在线 CPUs 集合发生变化，
则必须驱逐节点上的 Pod，并通过删除 kubelet 根目录中的状态文件 `cpu_manager_state`
来手动重置 CPU 管理器。
{{< /note >}}
<!--
@ -172,15 +157,15 @@ exclusive CPUs.
的 CPU 集合。`Guaranteed` pod 中的容器，如果声明了非整数值的 CPU `requests` ，也将运行在共享池的 CPU 上。只有 `Guaranteed` pod 中，指定了整数型 CPU `requests` 的容器，才会被分配独占 CPU 资源。
<!--
{{< note >}}
The kubelet requires a CPU reservation greater than zero be made
using either `--kube-reserved` and/or `--system-reserved` or `--reserved-cpus` when the static
policy is enabled. This is because zero CPU reservation would allow the shared
pool to become empty.
{{< /note >}}
--->
{{< note >}}
当启用 static 策略时，要求使用 `--kube-reserved` 和/或 `--system-reserved` 或 `--reserved-cpus` 来保证预留的 CPU 值大于零。 这是因为零预留 CPU 值可能使得共享池变空。
当启用 static 策略时，要求使用 `--kube-reserved` 和/或 `--system-reserved` 或
`--reserved-cpus` 来保证预留的 CPU 值大于零。
这是因为零预留 CPU 值可能使得共享池变空。
{{< /note >}}
<!--
@ -194,8 +179,12 @@ affinity and decreases context switches due to throttling for the CPU-bound
workload.
Consider the containers in the following pod specs:
--->
当 `Guaranteed` pod 调度到节点上时，如果其容器符合静态分配要求，相应的 CPU 会被从共享池中移除，并放置到容器的 cpuset 中。因为这些容器所使用的 CPU 受到调度域本身的限制，所以不需要使用 CFS 配额来进行 CPU 的绑定。换言之，容器 cpuset 中的 CPU 数量与 pod 规格中指定的整数型 CPU `limit` 相等。这种静态分配增强了 CPU 亲和性，减少了 CPU 密集的工作负载在节流时引起的上下文切换。
-->
当 `Guaranteed` Pod 调度到节点上时，如果其容器符合静态分配要求，
相应的 CPU 会被从共享池中移除，并放置到容器的 cpuset 中。
因为这些容器所使用的 CPU 受到调度域本身的限制，所以不需要使用 CFS 配额来进行 CPU 的绑定。
换言之，容器 cpuset 中的 CPU 数量与 Pod 规约中指定的整数型 CPU `limit` 相等。
这种静态分配增强了 CPU 亲和性，减少了 CPU 密集的工作负载在节流时引起的上下文切换。
考虑以下 Pod 规格的容器：
@ -209,8 +198,9 @@ spec:
<!--
This pod runs in the `BestEffort` QoS class because no resource `requests` or
`limits` are specified. It runs in the shared pool.
--->
该 pod 属于 `BestEffort` QoS 类型，因为其未指定 `requests` 或 `limits` 值。 所以该容器运行在共享 CPU 池中。
-->
该 Pod 属于 `BestEffort` QoS 类型，因为其未指定 `requests` 或 `limits` 值。
所以该容器运行在共享 CPU 池中。
```yaml
spec:
@ -228,8 +218,9 @@ spec:
This pod runs in the `Burstable` QoS class because resource `requests` do not
equal `limits` and the `cpu` quantity is not specified. It runs in the shared
pool.
--->
该 pod 属于 `Burstable` QoS 类型，因为其资源 `requests` 不等于 `limits`， 且未指定 `cpu` 数量。所以该容器运行在共享 CPU 池中。
-->
该 Pod 属于 `Burstable` QoS 类型，因为其资源 `requests` 不等于 `limits`，且未指定 `cpu` 数量。
所以该容器运行在共享 CPU 池中。
```yaml
spec:
@ -248,8 +239,9 @@ spec:
<!--
This pod runs in the `Burstable` QoS class because resource `requests` do not
equal `limits`. It runs in the shared pool.
--->
该 pod 属于 `Burstable` QoS 类型，因为其资源 `requests` 不等于 `limits`。所以该容器运行在共享 CPU 池中。
-->
该 pod 属于 `Burstable` QoS 类型，因为其资源 `requests` 不等于 `limits`。
所以该容器运行在共享 CPU 池中。
```yaml
spec:
@ -269,8 +261,10 @@ spec:
This pod runs in the `Guaranteed` QoS class because `requests` are equal to `limits`.
And the container's resource limit for the CPU resource is an integer greater than
or equal to one. The `nginx` container is granted 2 exclusive CPUs.
--->
该 pod 属于 `Guaranteed` QoS 类型，因为其 `requests` 值与 `limits`相等。同时，容器对 CPU 资源的限制值是一个大于或等于 1 的整数值。所以，该 `nginx` 容器被赋予 2 个独占 CPU。
-->
该 Pod 属于 `Guaranteed` QoS 类型，因为其 `requests` 值与 `limits`相等。
同时，容器对 CPU 资源的限制值是一个大于或等于 1 的整数值。
所以，该 `nginx` 容器被赋予 2 个独占 CPU。
```yaml
spec:
@ -290,8 +284,9 @@ spec:
This pod runs in the `Guaranteed` QoS class because `requests` are equal to `limits`.
But the container's resource limit for the CPU resource is a fraction. It runs in
the shared pool.
--->
该 pod 属于 `Guaranteed` QoS 类型，因为其 `requests` 值与 `limits`相等。但是容器对 CPU 资源的限制值是一个小数。所以该容器运行在共享 CPU 池中。
-->
该 Pod 属于 `Guaranteed` QoS 类型，因为其 `requests` 值与 `limits`相等。
但是容器对 CPU 资源的限制值是一个小数。所以该容器运行在共享 CPU 池中。
```yaml
spec:
@ -309,7 +304,9 @@ This pod runs in the `Guaranteed` QoS class because only `limits` are specified
and `requests` are set equal to `limits` when not explicitly specified. And the
container's resource limit for the CPU resource is an integer greater than or
equal to one. The `nginx` container is granted 2 exclusive CPUs.
--->
该 pod 属于 `Guaranteed` QoS 类型，因其指定了 `limits` 值，同时当未显式指定时，`requests` 值被设置为与 `limits` 值相等。同时，容器对 CPU 资源的限制值是一个大于或等于 1 的整数值。所以，该 `nginx` 容器被赋予 2 个独占 CPU。
-->
该 Pod 属于 `Guaranteed` QoS 类型，因其指定了 `limits` 值，同时当未显式指定时，
`requests` 值被设置为与 `limits` 值相等。
同时，容器对 CPU 资源的限制值是一个大于或等于 1 的整数值。
所以，该 `nginx` 容器被赋予 2 个独占 CPU。

77
content/zh/docs/tasks/administer-cluster/developing-cloud-controller-manager.md
View File

@ -1,52 +1,46 @@
---
reviewers:
- luxas
- thockin
- wlan0
title: 开发云控制器管理器
content_type: concept
content_type: task
---
<!--
---
reviewers:
- luxas
- thockin
- wlan0
title: Developing Cloud Controller Manager
content_type: concept
---
-->
<!-- overview -->
{{< feature-state for_k8s_version="v1.11" state="beta" >}}
<!--
In upcoming releases, Cloud Controller Manager will
be the preferred way to integrate Kubernetes with any cloud. This will ensure cloud providers
can develop their features independently from the core Kubernetes release cycles.**
-->
在即将发布的版本中，云控制器管理器将是把 Kubernetes 与任何云集成的首选方式。 这将确保驱动可以独立于核心 Kubernetes 发布周期开发其功能。
{{< feature-state for_k8s_version="1.8" state="alpha" >}}
<!--
Before going into how to build your own cloud controller manager, some background on how it works under the hood is helpful. The cloud controller manager is code from `kube-controller-manager` utilizing Go interfaces to allow implementations from any cloud to be plugged in. Most of the scaffolding and generic controller implementations will be in core, but it will always exec out to the cloud interfaces it is provided, so long as the [cloud provider interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go#L42-L62) is satisfied.
-->
在讨论如何构建自己的云控制器管理器之前，了解有关它如何工作的一些背景知识是有帮助的。云控制器管理器是来自 `kube-controller-manager` 的代码，利用 Go 接口允许插入任何云的实现。大多数框架和通用控制器的实现在 core，但只要满足 [云提供者接口](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go#L42-L62)，它就会始终执行它所提供的云接口。
<!--
To dive a little deeper into implementation details, all cloud controller managers will import packages from Kubernetes core, the only difference being each project will register their own cloud providers by calling [cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/cloud-provider/blob/master/plugins.go#L56-L66) where a global variable of available cloud providers is updated.
-->
为了深入了解实施细节，所有云控制器管理器都将从 Kubernetes 核心导入依赖包，唯一的区别是每个项目都会通过调用 [cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/cloud-provider/blob/master/plugins.go#L56-L66) 来注册自己的驱动，更新可用驱动的全局变量。
{{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="组件 cloud-controller-manager 是">}}
<!-- body -->
<!--
## Background
Since cloud providers develop and release at a different pace compared to the Kubernetes project, abstracting the provider-specific code to the `cloud-controller-manager` binary allows cloud vendors to evolve independently from the core Kubernetes code.
-->
## 背景
由于云驱动的开发和发布与 Kubernetes 项目本身步调不同，将特定于云环境
的代码抽象到 `cloud-controller-manager` 二进制组件有助于云厂商独立于
Kubernetes 核心代码推进其驱动开发。
<!--
The Kubernetes project provides skeleton cloud-controller-manager code with Go interfaces to allow you (or your cloud provider) to plug in your own implementations. This means that a cloud provider can implement a cloud-controller-manager by importing packages from Kubernetes core; each cloudprovider will register their own code by calling `cloudprovider.RegisterCloudProvider` to update a global variable of available cloud providers.
-->
Kubernetes 项目提供 cloud-controller-manager 的框架代码，其中包含 Go
语言的接口，便于你（或者你的云驱动提供者）接驳你自己的实现。
这意味着每个云驱动可以通过从 Kubernetes 核心代码导入软件包来实现一个
cloud-controller-manager；每个云驱动会通过调用
`cloudprovider.RegisterCloudProvider` 接口来注册其自身实现代码，从而更新
记录可用云驱动的全局变量。
<!--
## Developing
-->
@ -57,28 +51,35 @@ To dive a little deeper into implementation details, all cloud controller manage
<!--
To build an out-of-tree cloud-controller-manager for your cloud, follow these steps:
-->
要为您的云构建一个 out-of-tree 云控制器管理器，请按照下列步骤操作：
要为你的云环境构建一个 out-of-tree 云控制器管理器：
<!--
1. Create a go package with an implementation that satisfies [cloudprovider.Interface](https://git.k8s.io/kubernetes/pkg/cloudprovider/cloud.go).
2. Use [main.go in cloud-controller-manager](https://github.com/kubernetes/kubernetes/blob/master/cmd/cloud-controller-manager/controller-manager.go) from Kubernetes core as a template for your main.go. As mentioned above, the only difference should be the cloud package that will be imported.
3. Import your cloud package in `main.go`, ensure your package has an `init` block to run [cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/plugins.go#L42-L52).
-->
1. 使用满足 [cloudprovider.Interface](https://git.k8s.io/kubernetes/pkg/cloudprovider/cloud.go) 的实现创建一个 go 包。
2. 使用来自 Kubernetes 核心包的 [cloud-controller-manager 中的 main.go](https://github.com/kubernetes/kubernetes/blob/master/cmd/cloud-controller-manager/controller-manager.go) 作为 main.go 的模板。如上所述，唯一的区别应该是将导入的云包。
1. 使用满足 [cloudprovider.Interface](https://git.k8s.io/kubernetes/pkg/cloudprovider/cloud.go)
的实现创建一个 Go 语言包。
2. 使用来自 Kubernetes 核心代码库的
[cloud-controller-manager 中的 main.go](https://github.com/kubernetes/kubernetes/blob/master/cmd/cloud-controller-manager/controller-manager.go)
作为 main.go 的模板。如上所述，唯一的区别应该是将导入的云包。
3. 在 `main.go` 中导入你的云包，确保你的包有一个 `init` 块来运行 cloudprovider.RegisterCloudProvider。
<!--
Using existing out-of-tree cloud providers as an example may be helpful. You can find the list [here](/docs/tasks/administer-cluster/running-cloud-controller.md#examples).
Many cloud providers publish their controller manager code as open source. If you are creating
a new cloud-controller-manager from scratch, you could take an existing out-of-tree cloud
controller manager as your starting point.
-->
用现有的 out-of-tree 云驱动作为例子可能会有所帮助。你可以在这里找到 [清单](/docs/tasks/administer-cluster/running-cloud-controller.md#examples)。
很多云驱动都将其控制器管理器代码以开源代码的形式公开。
如果你在开发一个新的 cloud-controller-manager，你可以选择某个 out-of-tree
云控制器管理器作为出发点。
### In Tree
<!--
For in-tree cloud providers, you can run the in-tree cloud controller manager as a [Daemonset](/examples/admin/cloud/ccm-example.yaml) in your cluster. See the [running cloud controller manager docs](/docs/tasks/administer-cluster/running-cloud-controller.md) for more details.
For in-tree cloud providers, you can run the in-tree cloud controller manager as a {{< glossary_tooltip term_id="daemonset" >}} in your cluster. See [Cloud Controller Manager Administration](/docs/tasks/administer-cluster/running-cloud-controller/) for more details.
-->
对于 in-tree 驱动，您可以将 in-tree 云控制器管理器作为群集中的 [Daemonset](/examples/admin/cloud/ccm-example.yaml) 运行。有关详细信息，请参阅 [运行的云控制器管理器文档](/docs/tasks/administer-cluster/running-cloud-controller.md)。
对于 in-tree 驱动，你可以将 in-tree 云控制器管理器作为群集中的
{{< glossary_tooltip term_id="daemonset" text="Daemonset" >}} 来运行。
有关详细信息，请参阅[云控制器管理器管理](/zh/docs/tasks/administer-cluster/running-cloud-controller/)。

14
content/zh/docs/tasks/administer-cluster/limit-storage-consumption.md
View File

@ -3,13 +3,10 @@ title: 限制存储消耗
content_type: task
---
<!--
---
title: Limit Storage Consumption
content_type: task
---
-->
<!-- overview -->
<!--
@ -22,17 +19,15 @@ The following resources are used in the demonstration: [ResourceQuota](/docs/con
[LimitRange](/docs/tasks/administer-cluster/memory-default-namespace/),
and [PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/).
-->
演示中用到了以下资源：[ResourceQuota](/docs/concepts/policy/resource-quotas/)，[LimitRange](/docs/tasks/administer-cluster/memory-default-namespace/) 和 [PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/)。
演示中用到了以下资源：[ResourceQuota](/zh/docs/concepts/policy/resource-quotas/)，
[LimitRange](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) 和
[PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/)。
## {{% heading "prerequisites" %}}
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- steps -->
<!--
@ -139,6 +134,3 @@ cluster's storage budget without risk of any one project going over their allotm
-->
限制范围对象可以用来设置可请求的存储量上限，而资源配额对象则可以通过申领计数和累计存储容量有效地限制命名空间耗用的存储量。这两种机制使得集群管理员能够规划其集群存储预算而不会发生任一项目超量分配的风险。

147
content/zh/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md
View File

@ -1,15 +1,13 @@
---
title: 为命名空间配置CPU最小和最大限制
title: 为命名空间配置 CPU 最小和最大约束
content_type: task
weight: 40
---
<!--
---
title: Configure Minimum and Maximum CPU Constraints for a Namespace
content_type: task
weight: 40
---
-->
<!-- overview -->
@ -21,25 +19,19 @@ and Pods in a namespace. You specify minimum and maximum CPU values in a
object. If a Pod does not meet the constraints imposed by the LimitRange, it cannot be created
in the namespace.
-->
本章介绍命名空间中可以被容器和Pod使用的CPU资源的最小和最大值。你可以通过 [LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core) 对象声明 CPU 的最小和最大值. 如果 Pod 不能满足 LimitRange 的限制，它就不能在命名空间中创建。
本页介绍如何为命名空间中容器和 Pod 使用的 CPU 资源设置最小和最大值。
你可以通过
[LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core)
对象声明 CPU 的最小和最大值. 如果 Pod 不能满足 LimitRange 的限制，它就不能在命名空间中创建。
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!--
Each node in your cluster must have at least 1 CPU.
Your cluster must have at least 1 CPU available for use to run the task examples.
-->
你的集群中每个节点至少要有1个CPU。
你的集群中每个节点至少要有 1 个 CPU 可用才能运行本任务示例。
<!-- steps -->
@ -49,7 +41,6 @@ Each node in your cluster must have at least 1 CPU.
Create a namespace so that the resources you create in this exercise are
isolated from the rest of your cluster.
-->
## 创建命名空间
创建一个命名空间，以便本练习中创建的资源和集群的其余资源相隔离。
@ -63,7 +54,6 @@ kubectl create namespace constraints-cpu-example
Here's the configuration file for a LimitRange:
-->
## 创建 LimitRange 和 Pod
这里给出了 LimitRange 的配置文件：
@ -73,17 +63,15 @@ Here's the configuration file for a LimitRange:
<!--
Create the LimitRange:
-->
创建 LimitRange:
```shell
kubectl create -f https://k8s.io/examples/admin/resource/cpu-constraints.yaml --namespace=constraints-cpu-example
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints.yaml --namespace=constraints-cpu-example
```
<!--
View detailed information about the LimitRange:
-->
查看 LimitRange 详情：
```shell
@ -95,8 +83,8 @@ The output shows the minimum and maximum CPU constraints as expected. But
notice that even though you didn't specify default values in the configuration
file for the LimitRange, they were created automatically.
-->
输出结果显示 CPU 的最小和最大限制符合预期。但需要注意的是，尽管你在 LimitRange 的配置文件中你没有声明默认值，默认值也会被自动创建。
输出结果显示 CPU 的最小和最大限制符合预期。但需要注意的是，尽管你在 LimitRange
的配置文件中你没有声明默认值，默认值也会被自动创建。
```yaml
limits:
@ -127,45 +115,43 @@ CPU request and limit to the Container.
* 如果容器没有声明自己的 CPU 请求和限制，将为容器指定默认 CPU 请求和限制。
* 核查容器声明的 CPU 请求确保其大于或者等于200 millicpu。
* 核查容器声明的 CPU 请求确保其大于或者等于 200 millicpu。
* 核查容器声明的 CPU 限制确保其小于或者等于800 millicpu。
* 核查容器声明的 CPU 限制确保其小于或者等于 800 millicpu。
{{< note >}} 当创建 LimitRange 对象时，你也可以声明 huge-page 和 GPU 的限制。当这些资源同时声明了 'default' 和 ‘defaultRequest’ 参数时，两个参数值必须相同。 {{< /note >}}
<!--
When creating a `LimitRange` object, you can specify limits on huge-pages
or GPUs as well. However, when both `default` and `defaultRequest` are specified
on these resources, the two values must be the same.
-->
{{< note >}}
当创建 LimitRange 对象时，你也可以声明大页面和 GPU 的限制。
当这些资源同时声明了 'default' 和 'defaultRequest' 参数时，两个参数值必须相同。
{{< /note >}}
<!--
Here's the configuration file for a Pod that has one Container. The Container manifest
specifies a CPU request of 500 millicpu and a CPU limit of 800 millicpu. These satisfy the
minimum and maximum CPU constraints imposed by the LimitRange.
-->
这里给出了包含一个容器的 Pod 的配置文件。该容器声明了500 millicpu的 CPU 请求和800 millicpu的 CPU 限制。这些参数满足了 LimitRange 对象规定的 CPU 最小和最大限制。
这里给出了包含一个容器的 Pod 的配置文件。
该容器声明了 500 millicpu 的 CPU 请求和 800 millicpu 的 CPU 限制。
这些参数满足了 LimitRange 对象规定的 CPU 最小和最大限制。
{{< codenew file="admin/resource/cpu-constraints-pod.yaml" >}}
<!--
Create the Pod:
-->
创建Pod：
```shell
kubectl create -f https://k8s.io/examples/admin/resource/cpu-constraints-pod.yaml --namespace=constraints-cpu-example
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod.yaml --namespace=constraints-cpu-example
```
<!--
Verify that the Pod's Container is running:
-->
确认一下 Pod 中的容器在运行：
```shell
@ -175,7 +161,6 @@ kubectl get pod constraints-cpu-demo --namespace=constraints-cpu-example
<!--
View detailed information about the Pod:
-->
查看 Pod 的详情：
```shell
@ -186,8 +171,8 @@ kubectl get pod constraints-cpu-demo --output=yaml --namespace=constraints-cpu-e
The output shows that the Container has a CPU request of 500 millicpu and CPU limit
of 800 millicpu. These satisfy the constraints imposed by the LimitRange.
-->
输出结果表明容器的 CPU 请求为500 millicpu，CPU限制为800 millicpu。这些参数满足 LimitRange 规定的限制范围。
输出结果表明容器的 CPU 请求为 500 millicpu，CPU 限制为 800 millicpu。
这些参数满足 LimitRange 规定的限制范围。
```yaml
resources:
@ -200,7 +185,6 @@ resources:
<!--
## Delete the Pod
-->
## 删除 Pod
```shell
@ -213,28 +197,26 @@ kubectl delete pod constraints-cpu-demo --namespace=constraints-cpu-example
Here's the configuration file for a Pod that has one Container. The Container specifies a
CPU request of 500 millicpu and a cpu limit of 1.5 cpu.
-->
## 尝试创建一个超过最大 CPU 限制的 Pod
这里给出了包含一个容器的 Pod 的配置文件。容器声明了500 millicpu的CPU请求和1.5 cpu的 CPU 限制。
这里给出了包含一个容器的 Pod 的配置文件。容器声明了 500 millicpu 的 CPU
请求和 1.5 CPU 的 CPU 限制。
{{< codenew file="admin/resource/cpu-constraints-pod-2.yaml" >}}
<!--
Attempt to create the Pod:
-->
尝试创建 Pod：
```shell
kubectl create -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-2.yaml --namespace=constraints-cpu-example
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-2.yaml --namespace=constraints-cpu-example
```
<!--
The output shows that the Pod does not get created, because the Container specifies a CPU limit that is
too large:
-->
输出结果表明 Pod 没有创建成功，因为容器声明的 CPU 限制太大了：
```
@ -248,7 +230,6 @@ pods "constraints-cpu-demo-2" is forbidden: maximum cpu usage per Container is 8
Here's the configuration file for a Pod that has one Container. The Container specifies a
CPU request of 100 millicpu and a CPU limit of 800 millicpu.
-->
## 尝试创建一个不满足最小 CPU 请求的 Pod
这里给出了包含一个容器的 Pod 的配置文件。该容器声明了100 millicpu的 CPU 请求和800 millicpu的 CPU 限制。
@ -258,18 +239,16 @@ CPU request of 100 millicpu and a CPU limit of 800 millicpu.
<!--
Attempt to create the Pod:
-->
尝试创建 Pod：
```shell
kubectl create -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-3.yaml --namespace=constraints-cpu-example
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-3.yaml --namespace=constraints-cpu-example
```
<!--
The output shows that the Pod does not get created, because the Container specifies a CPU
request that is too small:
-->
输出结果显示 Pod 没有创建成功，因为容器声明的 CPU 请求太小了：
```
@ -283,27 +262,24 @@ pods "constraints-cpu-demo-4" is forbidden: minimum cpu usage per Container is 2
Here's the configuration file for a Pod that has one Container. The Container does not
specify a CPU request, and it does not specify a CPU limit.
-->
## 创建一个没有声明 CPU 请求和 CPU 限制的 Pod
## 创建一个没有声明CPU请求和CPU限制的Pod
这里给出了包含一个容器的Pod的配置文件。该容器没有声明CPU请求和CPU限制。
这里给出了包含一个容器的 Pod 的配置文件。该容器没有设定 CPU 请求和 CPU 限制。
{{< codenew file="admin/resource/cpu-constraints-pod-4.yaml" >}}
<!--
Create the Pod:
-->
创建 Pod：
```shell
kubectl create -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-4.yaml --namespace=constraints-cpu-example
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-4.yaml --namespace=constraints-cpu-example
```
<!--
View detailed information about the Pod:
-->
查看 Pod 的详情：
```
@ -314,8 +290,8 @@ kubectl get pod constraints-cpu-demo-4 --namespace=constraints-cpu-example --out
The output shows that the Pod's Container has a CPU request of 800 millicpu and a CPU limit of 800 millicpu.
How did the Container get those values?
-->
输出结果显示 Pod 的容器有个800 millicpu的 CPU 请求和800 millicpu的 CPU 限制。容器时怎样得到那些值的呢？
输出结果显示 Pod 的容器有个 800 millicpu 的 CPU 请求和 800 millicpu 的 CPU 限制。
容器是怎样得到那些值的呢？
```yaml
resources:
@ -330,8 +306,8 @@ Because your Container did not specify its own CPU request and limit, it was giv
[default CPU request and limit](/docs/tasks/administer-cluster/cpu-default-namespace/)
from the LimitRange.
-->
因为你的容器没有声明自己的 CPU 请求和限制，LimitRange 给它指定了[默认的CPU请求和限制](/docs/tasks/administer-cluster/cpu-default-namespace/)
因为你的 Container 没有声明自己的 CPU 请求和限制，LimitRange 给它指定了
[默认的 CPU 请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)
<!--
At this point, your Container might be running or it might not be running. Recall that a prerequisite
@ -342,8 +318,10 @@ enough CPU to accommodate the 800 millicpu request.
Delete your Pod:
-->
此时，你的容器可能运行也可能没有运行。回想一下，本任务的先决条件是你的节点要有1 个 CPU。如果你的每个节点仅有1个 CPU，那么可能没有任何一个节点可以满足800 millicpu的 CPU 请求。如果你在用的节点恰好有两个 CPU，那么你才可能有足够的 CPU来满足800 millicpu的请求。
此时，你的容器可能运行也可能没有运行。
回想一下，本任务的先决条件是你的节点要有 1 个 CPU。
如果你的每个节点仅有 1 个 CPU，那么可能没有任何一个节点可以满足 800 millicpu 的 CPU 请求。
如果你在用的节点恰好有两个 CPU，那么你才可能有足够的 CPU 来满足 800 millicpu 的请求。
```
kubectl delete pod constraints-cpu-demo-4 --namespace=constraints-cpu-example
@ -356,21 +334,18 @@ The maximum and minimum CPU constraints imposed on a namespace by a LimitRange a
when a Pod is created or updated. If you change the LimitRange, it does not affect
Pods that were created previously.
-->
## CPU 最小和最大限制的强制执行
只有当Pod创建或者更新时，LimitRange为命名空间规定的CPU最小和最大限制才会被强制执行。如果你对LimitRange进行修改，那不会影响此前创建的Pod。
只有当 Pod 创建或者更新时，LimitRange 为命名空间规定的 CPU 最小和最大限制才会被强制执行。
如果你对 LimitRange 进行修改，那不会影响此前创建的 Pod。
<!--
## Motivation for minimum and maximum CPU constraints
-->
## 最小和最大 CPU 限制范围的动机
<!--
As a cluster administrator, you might want to impose restrictions on the CPU resources that Pods can use.
For example:
-->
## 最小和最大 CPU 限制范围的动机
作为集群管理员，你可能想设定 Pod 可以使用的 CPU 资源限制。例如：
@ -383,18 +358,17 @@ You want to allow production workloads to consume up to 3 CPU, but you want deve
to 1 CPU. You create separate namespaces for production and development, and you apply CPU constraints to
each namespace.
-->
* 集群中的每个节点有两个 CPU。你不想接受任何请求超过2个 CPU 的 Pod，因为集群中没有节点可以支持这种请求。
* 你的生产和开发部门共享一个集群。你想允许生产工作负载消耗3个 CPU，而开发工作负载的消耗限制为1个 CPU。你为生产和开发创建不同的命名空间，并且你为每个命名空间都应用了 CPU 限制。
* 集群中的每个节点有两个 CPU。你不想接受任何请求超过 2 个 CPU 的 Pod，因为集群中没有节点可以支持这种请求。
* 你的生产和开发部门共享一个集群。你想允许生产工作负载消耗 3 个 CPU，
而开发部门工作负载的消耗限制为 1 个 CPU。
你可以为生产和开发创建不同的命名空间，并且为每个命名空间都应用 CPU 限制。
<!--
## Clean up
Delete your namespace:
-->
## 环境清理
## 清理
删除你的命名空间：
@ -402,11 +376,8 @@ Delete your namespace:
kubectl delete namespace constraints-cpu-example
```
## {{% heading "whatsnext" %}}
<!--
### For cluster administrators
@ -425,34 +396,24 @@ kubectl delete namespace constraints-cpu-example
### 集群管理员参考：
* [为命名空间配置默认内存请求和限制](/docs/tasks/administer-cluster/memory-default-namespace/)
* [为命名空间配置内存限制的最小值和最大值](/docs/tasks/administer-cluster/memory-constraint-namespace/)
* [为命名空间配置 CPU 限制的最小值和最大值](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
* [为命名空间配置内存和 CPU 配额](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)
* [为命名空间配置 Pod 配额](/docs/tasks/administer-cluster/quota-pod-namespace/)
* [为 API 对象配置配额](/docs/tasks/administer-cluster/quota-api-object/)
* [为命名空间配置默认内存请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
* [为命名空间配置内存限制的最小值和最大值](/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
* [为命名空间配置 CPU 限制的最小值和最大值](/zh/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
* [为命名空间配置内存和 CPU 配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
* [为命名空间配置 Pod 配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/)
* [为 API 对象配置配额](/zh/docs/tasks/administer-cluster/quota-api-object/)
<!--
### For app developers
* [Assign Memory Resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-memory-resource/)
* [Assign CPU Resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-cpu-resource/)
* [Configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/)
-->
### 应用开发者参考：
* [为容器和 Pod 分配内存资源](/docs/tasks/configure-pod-container/assign-memory-resource/)
* [为容器和 Pod 分配 CPU 资源](/docs/tasks/configure-pod-container/assign-cpu-resource/)
* [为 Pod 配置 Service 数量](/docs/tasks/configure-pod-container/quality-service-pod/)
* [为容器和 Pod 分配内存资源](/zh/docs/tasks/configure-pod-container/assign-memory-resource/)
* [为容器和 Pod 分配 CPU 资源](/zh/docs/tasks/configure-pod-container/assign-cpu-resource/)
* [为 Pod 配置 Service 数量](/zh/docs/tasks/configure-pod-container/quality-service-pod/)

113
content/zh/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md
View File

@ -1,15 +1,13 @@
---
title: 为命名空间配置默认的CPU请求和限制
title: 为命名空间配置默认的 CPU 请求和限制
content_type: task
weight: 20
---
<!--
---
title: Configure Default CPU Requests and Limits for a Namespace
content_type: task
weight: 20
---
-->
<!-- overview -->
@ -20,29 +18,24 @@ that has a default CPU limit, and the Container does not specify its own CPU lim
the Container is assigned the default CPU limit. Kubernetes assigns a default CPU request
under certain conditions that are explained later in this topic.
-->
本章介绍怎样为命名空间配置默认的 CPU 请求和限制。
一个 Kubernetes 集群可被划分为多个命名空间。如果在配置了 CPU 限制的命名空间创建容器，并且该容器没有声明自己的 CPU 限制，那么这个容器会被指定默认的 CPU 限制。Kubernetes 在一些特定情况还会指定 CPU 请求，本文后续章节将会对其进行解释。
一个 Kubernetes 集群可被划分为多个命名空间。如果在配置了 CPU 限制的命名空间创建容器，
并且该容器没有声明自己的 CPU 限制，那么这个容器会被指定默认的 CPU 限制。
Kubernetes 在一些特定情况还会指定 CPU 请求，本文后续章节将会对其进行解释。
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- steps -->
<!--
## Create a namespace
-->
## 创建命名空间
<!--
Create a namespace so that the resources you create in this exercise are
isolated from the rest of your cluster.
-->
## 创建命名空间
创建一个命名空间，以便本练习中创建的资源和集群的其余部分相隔离。
@ -52,14 +45,11 @@ kubectl create namespace default-cpu-example
<!--
## Create a LimitRange and a Pod
-->
创建 LimitRange 和 Pod
<!--
Here's the configuration file for a LimitRange object. The configuration specifies
a default CPU request and a default CPU limit.
-->
## 创建 LimitRange 和 Pod
这里给出了 LimitRange 对象的配置文件。该配置声明了一个默认的 CPU 请求和一个默认的 CPU 限制。
@ -68,11 +58,10 @@ a default CPU request and a default CPU limit.
<!--
Create the LimitRange in the default-cpu-example namespace:
-->
在命名空间 default-cpu-example 中创建 LimitRange 对象：
```shell
kubectl create -f https://k8s.io/examples/admin/resource/cpu-defaults.yaml --namespace=default-cpu-example
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults.yaml --namespace=default-cpu-example
```
<!--
@ -84,8 +73,8 @@ CPU limit of 1.
Here's the configuration file for a Pod that has one Container. The Container
does not specify a CPU request and limit.
-->
现在如果在 default-cpu-example 命名空间创建一个容器，该容器没有声明自己的 CPU 请求和限制时，将会给它指定默认的 CPU 请求0.5和默认的 CPU 限制值1.
现在如果在 default-cpu-example 命名空间创建一个容器，该容器没有声明自己的 CPU 请求和限制时，
将会给它指定默认的 CPU 请求0.5和默认的 CPU 限制值1.
这里给出了包含一个容器的 Pod 的配置文件。该容器没有声明 CPU 请求和限制。
@ -94,17 +83,15 @@ does not specify a CPU request and limit.
<!--
Create the Pod.
-->
创建 Pod。
```shell
kubectl create -f https://k8s.io/examples/admin/resource/cpu-defaults-pod.yaml --namespace=default-cpu-example
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults-pod.yaml --namespace=default-cpu-example
```
<!--
View the Pod's specification:
-->
查看该 Pod 的声明：
```shell
@ -115,7 +102,6 @@ kubectl get pod default-cpu-demo --output=yaml --namespace=default-cpu-example
The output shows that the Pod's Container has a CPU request of 500 millicpus and
a CPU limit of 1 cpu. These are the default values specified by the LimitRange.
-->
输出显示该 Pod 的容器有一个500 millicpus的 CPU 请求和一个1 cpu的 CPU 限制。这些是 LimitRange 声明的默认值。
```shell
@ -132,14 +118,11 @@ containers:
<!--
## What if you specify a Container's limit, but not its request?
-->
## 你只声明容器的限制，而不声明请求会怎么样？
<!--
Here's the configuration file for a Pod that has one Container. The Container
specifies a CPU limit, but not a request:
-->
## 你只声明容器的限制，而不声明请求会怎么样？
这是包含一个容器的 Pod 的配置文件。该容器声明了 CPU 限制，而没有声明 CPU 请求。
@ -148,17 +131,15 @@ specifies a CPU limit, but not a request:
<!--
Create the Pod:
-->
创建 Pod
```shell
kubectl create -f https://k8s.io/examples/admin/resource/cpu-defaults-pod-2.yaml --namespace=default-cpu-example
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults-pod-2.yaml --namespace=default-cpu-example
```
<!--
View the Pod specification:
-->
查看 Pod 的声明：
```
@ -169,7 +150,6 @@ kubectl get pod default-cpu-demo-2 --output=yaml --namespace=default-cpu-example
The output shows that the Container's CPU request is set to match its CPU limit.
Notice that the Container was not assigned the default CPU request value of 0.5 cpu.
-->
输出显示该容器的 CPU 请求和 CPU 限制设置相同。注意该容器没有被指定默认的 CPU 请求值0.5 cpu。
```
@ -182,14 +162,11 @@ resources:
<!--
## What if you specify a Container's request, but not its limit?
-->
## 你只声明容器的请求，而不声明它的限制会怎么样？
<!--
Here's the configuration file for a Pod that has one Container. The Container
specifies a CPU request, but not a limit:
-->
## 你只声明容器的请求，而不声明它的限制会怎么样？
这里给出了包含一个容器的 Pod 的配置文件。该容器声明了 CPU 请求，而没有声明 CPU 限制。
@ -198,18 +175,16 @@ specifies a CPU request, but not a limit:
<!--
Create the Pod:
-->
创建 Pod：
```shell
kubectl create -f https://k8s.io/examples/admin/resource/cpu-defaults-pod-3.yaml --namespace=default-cpu-example
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults-pod-3.yaml --namespace=default-cpu-example
```
<!--
View the Pod specification:
-->
查看 Pod 的声明：
查看 Pod 的规约：
```
kubectl get pod default-cpu-demo-3 --output=yaml --namespace=default-cpu-example
@ -220,8 +195,8 @@ The output shows that the Container's CPU request is set to the value specified
Container's configuration file. The Container's CPU limit is set to 1 cpu, which is the
default CPU limit for the namespace.
-->
结果显示该容器的 CPU 请求被设置为容器配置文件中声明的数值。容器的CPU限制被设置为1 cpu，即该命名空间的默认 CPU 限制值。
结果显示该容器的 CPU 请求被设置为容器配置文件中声明的数值。
容器的CPU限制被设置为 1 CPU，即该命名空间的默认 CPU 限制值。
```
resources:
@ -233,11 +208,7 @@ resources:
<!--
## Motivation for default CPU limits and requests
-->
## 默认 CPU 限制和请求的动机
<!--
If your namespace has a
[resource quota](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/),
it is helpful to have a default value in place for CPU limit.
@ -249,69 +220,49 @@ Here are two of the restrictions that a resource quota imposes on a namespace:
If a Container does not specify its own CPU limit, it is given the default limit, and then
it can be allowed to run in a namespace that is restricted by a quota.
-->
## 默认 CPU 限制和请求的动机
如果你的命名空间有一个[资源配额](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/),那么有一个默认的 CPU 限制是有帮助的。这里有两条资源配额强加给命名空间的限制：
如果你的命名空间有一个
[资源配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)，
那么有一个默认的 CPU 限制是有帮助的。这里有资源配额强加给命名空间的两条限制：
* 命名空间中运行的每个容器必须有自己的 CPU 限制。
* 命名空间中所有容器使用的 CPU 总和不能超过一个声明值。
如果容器没有声明自己的 CPU 限制，将会给它一个默认限制，这样它就能被允许运行在一个有配额限制的命名空间中。
## {{% heading "whatsnext" %}}
<!--
### For cluster administrators
-->
### 集群管理员参考
<!--
* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/)
* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/)
* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
* [Configure Memory and CPU Quotas for a Namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)
* [Configure a Pod Quota for a Namespace](/docs/tasks/administer-cluster/quota-pod-namespace/)
* [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/)
-->
### 集群管理员参考
* [为命名空间配置默认内存请求和限制](/docs/tasks/administer-cluster/memory-default-namespace/)
* [为命名空间配置内存限制的最小值和最大值](/docs/tasks/administer-cluster/memory-constraint-namespace/)
* [为命名空间配置 CPU 限制的最小值和最大值](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
* [为命名空间配置内存和 CPU 配额](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)
* [为命名空间配置 Pod 配额](/docs/tasks/administer-cluster/quota-pod-namespace/)
* [为 API 对象配置配额](/docs/tasks/administer-cluster/quota-api-object/)
* [为命名空间配置默认内存请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
* [为命名空间配置内存限制的最小值和最大值](/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
* [为命名空间配置 CPU 限制的最小值和最大值](/zh/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
* [为命名空间配置内存和 CPU 配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
* [为命名空间配置 Pod 配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/)
* [为 API 对象配置配额](/zh/docs/tasks/administer-cluster/quota-api-object/)
<!--
### For app developers
-->
### 应用开发者参考
<!--
* [Assign Memory Resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-memory-resource/)
* [Assign CPU Resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-cpu-resource/)
* [Configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/)
-->
### 应用开发者参考
* [为容器和 Pod 分配内存资源](/docs/tasks/configure-pod-container/assign-memory-resource/)
* [为容器和 Pod 分配 CPU 资源](/docs/tasks/configure-pod-container/assign-cpu-resource/)
* [为 Pod 配置 Service 数量](/docs/tasks/configure-pod-container/quality-service-pod/)
* [为容器和 Pod 分配内存资源](/zh/docs/tasks/configure-pod-container/assign-memory-resource/)
* [为容器和 Pod 分配 CPU 资源](/zh/docs/tasks/configure-pod-container/assign-cpu-resource/)
* [为 Pod 配置 Service 数量](/zh/docs/tasks/configure-pod-container/quality-service-pod/)

121
content/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md
View File

@ -5,11 +5,9 @@ weight: 30
---
<!--
---
title: Configure Minimum and Maximum Memory Constraints for a Namespace
content_type: task
weight: 30
---
-->
<!-- overview -->
@ -21,25 +19,18 @@ running in a namespace. You specify minimum and maximum memory values in a
object. If a Pod does not meet the constraints imposed by the LimitRange,
it cannot be created in the namespace.
-->
此页面介绍如何设置在命名空间中运行的容器使用的内存的最小值和最大值。 您可以在 [LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core)对象中指定最小和最大内存值。 如果 Pod 不满足 LimitRange 施加的约束，则无法在命名空间中创建它。
本页介绍如何设置在命名空间中运行的容器使用的内存的最小值和最大值。 你可以在
[LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core)
对象中指定最小和最大内存值。如果 Pod 不满足 LimitRange 施加的约束，则无法在命名空间中创建它。
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!--
Each node in your cluster must have at least 1 GiB of memory.
-->
集群中每个节点必须至少要有1 GiB 的内存。
集群中每个节点必须至少要有 1 GiB 的内存。
<!-- steps -->
@ -49,7 +40,6 @@ Each node in your cluster must have at least 1 GiB of memory.
Create a namespace so that the resources you create in this exercise are
isolated from the rest of your cluster.
-->
## 创建命名空间
创建一个命名空间，以便在此练习中创建的资源与群集的其余资源隔离。
@ -63,28 +53,24 @@ kubectl create namespace constraints-mem-example
Here's the configuration file for a LimitRange:
-->
## 创建 LimitRange 和 Pod
下面是 LimitRange 的配置文件：
{{< codenew file="admin/resource/memory-constraints.yaml" >}}
<!--
Create the LimitRange:
-->
创建 LimitRange:
```shell
kubectl create -f https://k8s.io/examples/admin/resource/memory-constraints.yaml --namespace=constraints-mem-example
kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints.yaml --namespace=constraints-mem-example
```
<!--
View detailed information about the LimitRange:
-->
查看 LimitRange 的详情：
```shell
@ -96,8 +82,7 @@ The output shows the minimum and maximum memory constraints as expected. But
notice that even though you didn't specify default values in the configuration
file for the LimitRange, they were created automatically.
-->
输出显示预期的最小和最大内存约束。 但请注意，即使您没有在 LimitRange 的配置文件中指定默认值，也会自动创建它们。
输出显示预期的最小和最大内存约束。 但请注意，即使你没有在 LimitRange 的配置文件中指定默认值，也会自动创建它们。
```
limits:
@ -127,7 +112,6 @@ Here's the configuration file for a Pod that has one Container. The Container ma
specifies a memory request of 600 MiB and a memory limit of 800 MiB. These satisfy the
minimum and maximum memory constraints imposed by the LimitRange.
-->
现在，只要在 constraints-mem-example 命名空间中创建容器，Kubernetes 就会执行下面的步骤：
* 如果 Container 未指定自己的内存请求和限制，将为它指定默认的内存请求和限制。
@ -136,24 +120,23 @@ minimum and maximum memory constraints imposed by the LimitRange.
* 验证 Container 的内存限制是否小于或等于1 GiB。
这里给出了包含一个 Container 的 Pod 配置文件。Container 声明了600 MiB 的内存请求和800 MiB 的内存限制， 这些满足了 LimitRange 施加的最小和最大内存约束。
这里给出了包含一个 Container 的 Pod 配置文件。Container 声明了 600 MiB 的内存请求和
800 MiB 的内存限制， 这些满足了 LimitRange 施加的最小和最大内存约束。
{{< codenew file="admin/resource/memory-constraints-pod.yaml" >}}
<!--
Create the Pod:
-->
创建 Pod：
```shell
kubectl create -f https://k8s.io/examples/admin/resource/memory-constraints-pod.yaml --namespace=constraints-mem-example
kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod.yaml --namespace=constraints-mem-example
```
<!--
Verify that the Pod's Container is running:
-->
确认下 Pod 中的容器在运行：
```shell
@ -163,7 +146,6 @@ kubectl get pod constraints-mem-demo --namespace=constraints-mem-example
<!--
View detailed information about the Pod:
-->
查看 Pod 详情：
```shell
@ -174,7 +156,6 @@ kubectl get pod constraints-mem-demo --output=yaml --namespace=constraints-mem-e
The output shows that the Container has a memory request of 600 MiB and a memory limit
of 800 MiB. These satisfy the constraints imposed by the LimitRange.
-->
输出结果显示容器的内存请求为600 MiB，内存限制为800 MiB。这些满足了 LimitRange 设定的限制范围。
```yaml
@ -188,7 +169,6 @@ resources:
<!--
Delete your Pod:
-->
删除你创建的 Pod：
```shell
@ -201,7 +181,6 @@ kubectl delete pod constraints-mem-demo --namespace=constraints-mem-example
Here's the configuration file for a Pod that has one Container. The Container specifies a
memory request of 800 MiB and a memory limit of 1.5 GiB.
-->
## 尝试创建一个超过最大内存限制的 Pod
这里给出了包含一个容器的 Pod 的配置文件。容器声明了800 MiB 的内存请求和1.5 GiB 的内存限制。
@ -211,18 +190,16 @@ memory request of 800 MiB and a memory limit of 1.5 GiB.
<!--
Attempt to create the Pod:
-->
尝试创建 Pod:
```shell
kubectl create -f https://k8s.io/examples/admin/resource/memory-constraints-pod-2.yaml --namespace=constraints-mem-example
kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod-2.yaml --namespace=constraints-mem-example
```
<!--
The output shows that the Pod does not get created, because the Container specifies a memory limit that is
too large:
-->
输出结果显示 Pod 没有创建成功，因为容器声明的内存限制太大了：
```
@ -236,7 +213,6 @@ pods "constraints-mem-demo-2" is forbidden: maximum memory usage per Container i
Here's the configuration file for a Pod that has one Container. The Container specifies a
memory request of 100 MiB and a memory limit of 800 MiB.
-->
## 尝试创建一个不满足最小内存请求的 Pod
这里给出了包含一个容器的 Pod 的配置文件。容器声明了100 MiB 的内存请求和800 MiB 的内存限制。
@ -246,18 +222,16 @@ memory request of 100 MiB and a memory limit of 800 MiB.
<!--
Attempt to create the Pod:
-->
尝试创建 Pod：
```shell
kubectl create -f https://k8s.io/examples/admin/resource/memory-constraints-pod-3.yaml --namespace=constraints-mem-example
kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod-3.yaml --namespace=constraints-mem-example
```
<!--
The output shows that the Pod does not get created, because the Container specifies a memory
request that is too small:
-->
输出结果显示 Pod 没有创建成功，因为容器声明的内存请求太小了：
```
@ -271,7 +245,6 @@ pods "constraints-mem-demo-3" is forbidden: minimum memory usage per Container i
Here's the configuration file for a Pod that has one Container. The Container does not
specify a memory request, and it does not specify a memory limit.
-->
## 创建一个没有声明内存请求和限制的 Pod
这里给出了包含一个容器的 Pod 的配置文件。容器没有声明内存请求，也没有声明内存限制。
@ -281,17 +254,15 @@ specify a memory request, and it does not specify a memory limit.
<!--
Create the Pod:
-->
创建 Pod：
```shell
kubectl create -f https://k8s.io/examples/admin/resource/memory-constraints-pod-4.yaml --namespace=constraints-mem-example
kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod-4.yaml --namespace=constraints-mem-example
```
<!--
View detailed information about the Pod:
-->
查看 Pod 详情：
```
@ -302,7 +273,6 @@ kubectl get pod constraints-mem-demo-4 --namespace=constraints-mem-example --out
The output shows that the Pod's Container has a memory request of 1 GiB and a memory limit of 1 GiB.
How did the Container get those values?
-->
输出结果显示 Pod 的内存请求为1 GiB，内存限制为1 GiB。容器怎样获得哪些数值呢？
```
@ -318,8 +288,8 @@ Because your Container did not specify its own memory request and limit, it was
[default memory request and limit](/docs/tasks/administer-cluster/memory-default-namespace/)
from the LimitRange.
-->
因为你的容器没有声明自己的内存请求和限制，它从 LimitRange 那里获得了[默认的内存请求和限制](/docs/tasks/administer-cluster/memory-default-namespace/)。
因为你的容器没有声明自己的内存请求和限制，它从 LimitRange 那里获得了
[默认的内存请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)。
<!--
At this point, your Container might be running or it might not be running. Recall that a prerequisite
@ -330,8 +300,9 @@ enough space to accommodate the 1 GiB request.
Delete your Pod:
-->
此时，你的容器可能运行起来也可能没有运行起来。回想一下我们本次任务的先决条件是你的每个节点都至少有1 GiB 的内存。如果你的每个节点都只有1 GiB 的内存，那将没有一个节点拥有足够的可分配内存来满足1 GiB 的内存请求。
此时，你的容器可能运行起来也可能没有运行起来。
回想一下我们本次任务的先决条件是你的每个节点都至少有1 GiB 的内存。
如果你的每个节点都只有1 GiB 的内存，那将没有一个节点拥有足够的可分配内存来满足1 GiB 的内存请求。
删除你的 Pod：
@ -346,15 +317,14 @@ The maximum and minimum memory constraints imposed on a namespace by a LimitRang
when a Pod is created or updated. If you change the LimitRange, it does not affect
Pods that were created previously.
-->
## 强制执行内存最小和最大限制
LimitRange 为命名空间设定的最小和最大内存限制只有在 Pod 创建和更新时才会强制执行。如果你更新 LimitRange，它不会影响此前创建的 Pod。
LimitRange 为命名空间设定的最小和最大内存限制只有在 Pod 创建和更新时才会强制执行。
如果你更新 LimitRange，它不会影响此前创建的 Pod。
<!--
## Motivation for minimum and maximum memory constraints
-->
## 设置内存最小和最大限制的动因
<!--
@ -362,25 +332,26 @@ As a cluster administrator, you might want to impose restrictions on the amount
For example:
* Each Node in a cluster has 2 GB of memory. You do not want to accept any Pod that requests
more than 2 GB of memory, because no Node in the cluster can support the request.
more than 2 GB of memory, because no Node in the cluster can support the request.
* A cluster is shared by your production and development departments.
You want to allow production workloads to consume up to 8 GB of memory, but
you want development workloads to be limited to 512 MB. You create separate namespaces
for production and development, and you apply memory constraints to each namespace.
You want to allow production workloads to consume up to 8 GB of memory, but
you want development workloads to be limited to 512 MB. You create separate namespaces
for production and development, and you apply memory constraints to each namespace.
-->
做为集群管理员，你可能想规定 Pod 可以使用的内存总量限制。例如：
* 集群的每个节点有2 GB 内存。你不想接受任何请求超过2 GB 的 Pod，因为集群中没有节点可以满足。
* 集群的每个节点有 2 GB 内存。你不想接受任何请求超过 2 GB 的 Pod，因为集群中没有节点可以满足。
* 集群由生产部门和开发部门共享。你希望允许产品部门的负载最多耗用 8 GB 内存，
但是开发部门的负载最多可使用 512 MiB。
这时，你可以为产品部门和开发部门分别创建名字空间，并为各个名字空间设置内存约束。
<!--
## Clean up
Delete your namespace:
-->
## 数据清理
## 清理
删除你的命名空间：
@ -388,57 +359,39 @@ Delete your namespace:
kubectl delete namespace constraints-mem-example
```
## {{% heading "whatsnext" %}}
<!--
### For cluster administrators
* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/)
* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/cpu-default-namespace/)
* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
* [Configure Memory and CPU Quotas for a Namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)
* [Configure a Pod Quota for a Namespace](/docs/tasks/administer-cluster/quota-pod-namespace/)
* [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/)
-->
### 集群管理员参考
* [为命名空间配置默认内存请求和限制](/docs/tasks/administer-cluster/memory-default-namespace/)
* [为命名空间配置内存限制的最小值和最大值](/docs/tasks/administer-cluster/memory-constraint-namespace/)
* [为命名空间配置 CPU 限制的最小值和最大值](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
* [为命名空间配置内存和 CPU 配额](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)
* [为命名空间配置 Pod 配额](/docs/tasks/administer-cluster/quota-pod-namespace/)
* [为 API 对象配置配额](/docs/tasks/administer-cluster/quota-api-object/)
* [为命名空间配置默认内存请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
* [为命名空间配置内存限制的最小值和最大值](/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
* [为命名空间配置 CPU 限制的最小值和最大值](/zh/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
* [为命名空间配置内存和 CPU 配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
* [为命名空间配置 Pod 配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/)
* [为 API 对象配置配额](/zh/docs/tasks/administer-cluster/quota-api-object/)
<!--
### For app developers
* [Assign Memory Resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-memory-resource/)
* [Assign CPU Resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-cpu-resource/)
* [Configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/)
-->
### 应用开发者参考
* [为容器和 Pod 分配内存资源](/docs/tasks/configure-pod-container/assign-memory-resource/)
* [为容器和 Pod 分配 CPU 资源](/docs/tasks/configure-pod-container/assign-cpu-resource/)
* [为 Pod 配置 Service 数量](/docs/tasks/configure-pod-container/quality-service-pod/)
* [为容器和 Pod 分配内存资源](/zh/docs/tasks/configure-pod-container/assign-memory-resource/)
* [为容器和 Pod 分配 CPU 资源](/zh/docs/tasks/configure-pod-container/assign-cpu-resource/)
* [为 Pod 配置 Service 数量](/zh/docs/tasks/configure-pod-container/quality-service-pod/)

112
content/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md
View File

@ -5,11 +5,9 @@ weight: 10
---
<!--
---
title: Configure Default Memory Requests and Limits for a Namespace
content_type: task
weight: 10
---
-->
<!-- overview -->
@ -21,35 +19,29 @@ does not specify its own memory limit, then the Container is assigned the defaul
Kubernetes assigns a default memory request under certain conditions that are explained later in this topic.
-->
本文介绍怎样给命名空间配置默认的内存请求和限制。如果在一个有默认内存限制的命名空间创建容器，该容器没有声明自己的内存限制时，将会被指定默认内存限制。Kubernetes 还为某些情况指定了默认的内存请求，本章后面会进行介绍。
本文介绍怎样给命名空间配置默认的内存请求和限制。
如果在一个有默认内存限制的命名空间创建容器，该容器没有声明自己的内存限制时，
将会被指定默认内存限制。
Kubernetes 还为某些情况指定了默认的内存请求，本章后面会进行介绍。
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!--
Each node in your cluster must have at least 2 GiB of memory.
-->
你的集群中的每个节点必须至少有2 GiB的内存。
你的集群中的每个节点必须至少有 2 GiB 的内存。
<!-- steps -->
<!--
## Create a namespace
-->
## 创建命名空间
<!--
Create a namespace so that the resources you create in this exercise are
isolated from the rest of your cluster.
-->
## 创建命名空间
创建一个命名空间，以便本练习中所建的资源与集群的其余资源相隔离。
@ -59,14 +51,11 @@ kubectl create namespace default-mem-example
<!--
## Create a LimitRange and a Pod
-->
## 创建 LimitRange 和 Pod
<!--
Here's the configuration file for a LimitRange object. The configuration specifies
a default memory request and a default memory limit.
-->
## 创建 LimitRange 和 Pod
这里给出了一个限制范围对象的配置文件。该配置声明了一个默认的内存请求和一个默认的内存限制。
@ -75,11 +64,10 @@ a default memory request and a default memory limit.
<!--
Create the LimitRange in the default-mem-example namespace:
-->
在 default-mem-example 命名空间创建限制范围：
```shell
kubectl create -f https://k8s.io/examples/admin/resource/memory-defaults.yaml --namespace=default-mem-example
kubectl apply -f https://k8s.io/examples/admin/resource/memory-defaults.yaml --namespace=default-mem-example
```
<!--
@ -91,25 +79,23 @@ memory limit of 512 MiB.
Here's the configuration file for a Pod that has one Container. The Container
does not specify a memory request and limit.
-->
现在，如果在 default-mem-example 命名空间创建容器，并且该容器没有声明自己的内存请求和限制值，它将被指定一个默认的内存请求256 MiB和一个默认的内存限制512 Mib。
现在，如果在 default-mem-example 命名空间创建容器，并且该容器没有声明自己的内存请求和限制值，
它将被指定默认的内存请求 256 MiB 和默认的内存限制 512 MiB。
{{< codenew file="admin/resource/memory-defaults-pod.yaml" >}}
<!--
Create the Pod.
-->
创建 Pod
```shell
kubectl create -f https://k8s.io/examples/admin/resource/memory-defaults-pod.yaml --namespace=default-mem-example
kubectl apply -f https://k8s.io/examples/admin/resource/memory-defaults-pod.yaml --namespace=default-mem-example
```
<!--
View detailed information about the Pod:
-->
查看 Pod 的详情：
```shell
@ -120,8 +106,8 @@ kubectl get pod default-mem-demo --output=yaml --namespace=default-mem-example
The output shows that the Pod's Container has a memory request of 256 MiB and
a memory limit of 512 MiB. These are the default values specified by the LimitRange.
-->
输出内容显示该Pod的容器有一个256 MiB的内存请求和一个512 MiB的内存限制。这些都是限制范围声明的默认值。
输出内容显示该 Pod 的容器有 256 MiB 的内存请求和 512 MiB 的内存限制。
这些都是 LimitRange 设置的默认值。
```shell
containers:
@ -138,7 +124,6 @@ containers:
<!--
Delete your Pod:
-->
删除你的 Pod：
```shell
@ -147,14 +132,11 @@ kubectl delete pod default-mem-demo --namespace=default-mem-example
<!--
## What if you specify a Container's limit, but not its request?
-->
## 声明容器的限制而不声明它的请求会怎么样？
<!--
Here's the configuration file for a Pod that has one Container. The Container
specifies a memory limit, but not a request:
-->
## 声明容器的限制而不声明它的请求会怎么样？
这里给出了包含一个容器的 Pod 的配置文件。该容器声明了内存限制，而没有声明内存请求：
@ -163,17 +145,15 @@ specifies a memory limit, but not a request:
<!--
Create the Pod:
-->
创建 Pod：
```shell
kubectl create -f https://k8s.io/examples/admin/resource/memory-defaults-pod-2.yaml --namespace=default-mem-example
kubectl apply -f https://k8s.io/examples/admin/resource/memory-defaults-pod-2.yaml --namespace=default-mem-example
```
<!--
View detailed information about the Pod:
-->
查看 Pod 的详情：
```shell
@ -184,8 +164,7 @@ kubectl get pod default-mem-demo-2 --output=yaml --namespace=default-mem-example
The output shows that the Container's memory request is set to match its memory limit.
Notice that the Container was not assigned the default memory request value of 256Mi.
-->
输出结果显示容器的内存请求被设置为它的内存限制相同的值。注意该容器没有被指定默认的内存请求值256Mi。
输出结果显示容器的内存请求被设置为它的内存限制相同的值。注意该容器没有被指定默认的内存请求值 256MiB。
```
resources:
@ -198,14 +177,12 @@ resources:
<!--
## What if you specify a Container's request, but not its limit?
-->
## 声明容器的内存请求而不声明内存限制会怎么样？
<!--
Here's the configuration file for a Pod that has one Container. The Container
specifies a memory request, but not a limit:
-->
这里给出了一个包含一个容器的 Pod 的配置文件。该容器声明了内存请求，但没有内存限制：
{{< codenew file="admin/resource/memory-defaults-pod-3.yaml" >}}
@ -213,17 +190,15 @@ specifies a memory request, but not a limit:
<!--
Create the Pod:
-->
创建 Pod：
```shell
kubectl create -f https://k8s.io/examples/admin/resource/memory-defaults-pod-3.yaml --namespace=default-mem-example
kubectl apply -f https://k8s.io/examples/admin/resource/memory-defaults-pod-3.yaml --namespace=default-mem-example
```
<!--
View the Pod's specification:
-->
查看 Pod 声明：
```shell
@ -235,8 +210,8 @@ The output shows that the Container's memory request is set to the value specifi
Container's configuration file. The Container's memory limit is set to 512Mi, which is the
default memory limit for the namespace.
-->
输出结果显示该容器的内存请求被设置为了容器配置文件中声明的数值。容器的内存限制被设置为512Mi，即命名空间的默认内存限制。
输出结果显示该容器的内存请求被设置为了容器配置文件中声明的数值。
容器的内存限制被设置为 512MiB，即命名空间的默认内存限制。
```
resources:
@ -248,23 +223,20 @@ resources:
<!--
## Motivation for default memory limits and requests
-->
## 设置默认内存限制和请求的动机
<!--
If your namespace has a resource quota,
it is helpful to have a default value in place for memory limit.
Here are two of the restrictions that a resource quota imposes on a namespace:
-->
## 设置默认内存限制和请求的动机
如果你的命名空间有资源配额，那么默认内存限制是很有帮助的。下面是一个例子，通过资源配额为命名空间设置两项约束：
如果你的命名空间有资源配额，那么默认内存限制是很有帮助的。
下面是一个例子，通过资源配额为命名空间设置两项约束：
<!--
* Every Container that runs in the namespace must have its own memory limit.
* The total amount of memory used by all Containers in the namespace must not exceed a specified limit.
-->
* 运行在命名空间中的每个容器必须有自己的内存限制。
* 命名空间中所有容器的内存使用量之和不能超过声明的限制值。
@ -272,21 +244,13 @@ Here are two of the restrictions that a resource quota imposes on a namespace:
If a Container does not specify its own memory limit, it is given the default limit, and then
it can be allowed to run in a namespace that is restricted by a quota.
-->
如果一个容器没有声明自己的内存限制，会被指定默认限制，然后它才会被允许在限定了配额的命名空间中运行。
## {{% heading "whatsnext" %}}
<!--
### For cluster administrators
-->
### 集群管理员参考
<!--
* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/cpu-default-namespace/)
* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/)
@ -299,37 +263,27 @@ it can be allowed to run in a namespace that is restricted by a quota.
* [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/)
-->
### 集群管理员参考
* [为命名空间配置默认的 CPU 请求和限制](/docs/tasks/administer-cluster/cpu-default-namespace/)
* [为命名空间配置最小和最大内存限制](/docs/tasks/administer-cluster/memory-constraint-namespace/)
* [为命名空间配置最小和最大 CPU 限制](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
* [为命名空间配置内存和 CPU 配额](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)
* [为命名空间配置 Pod 配额](/docs/tasks/administer-cluster/quota-pod-namespace/)
* [为 API 对象配置配额](/docs/tasks/administer-cluster/quota-api-object/)
* [为命名空间配置默认的 CPU 请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)
* [为命名空间配置最小和最大内存限制](/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
* [为命名空间配置最小和最大 CPU 限制](/zh/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
* [为命名空间配置内存和 CPU 配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
* [为命名空间配置 Pod 配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/)
* [为 API 对象配置配额](/zh/docs/tasks/administer-cluster/quota-api-object/)
<!--
### For app developers
-->
### 应用开发者参考
<!--
* [Assign Memory Resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-memory-resource/)
* [Assign CPU Resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-cpu-resource/)
* [Configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/)
-->
### 应用开发者参考
* [为容器和 Pod 分配内存资源](/docs/tasks/configure-pod-container/assign-memory-resource/)
* [为容器和 Pod 分配 CPU 资源](/docs/tasks/configure-pod-container/assign-cpu-resource/)
* [为 Pod 配置服务数量](/docs/tasks/configure-pod-container/quality-service-pod/)
* [为容器和 Pod 分配内存资源](/zh/docs/tasks/configure-pod-container/assign-memory-resource/)
* [为容器和 Pod 分配 CPU 资源](/zh/docs/tasks/configure-pod-container/assign-cpu-resource/)
* [为 Pod 配置服务数量](/zh/docs/tasks/configure-pod-container/quality-service-pod/)

86
content/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md
View File

@ -5,11 +5,9 @@ weight: 50
---
<!--
---
title: Configure Memory and CPU Quotas for a Namespace
content_type: task
weight: 50
---
-->
<!-- overview -->
@ -20,27 +18,18 @@ can be used by all Containers running in a namespace. You specify quotas in a
[ResourceQuota](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcequota-v1-core)
object.
-->
本文介绍怎样为命名空间设置容器可用的内存和 CPU 总量。你可以通过 [ResourceQuota](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcequota-v1-core)
本文介绍怎样为命名空间设置容器可用的内存和 CPU 总量。你可以通过
[ResourceQuota](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcequota-v1-core)
对象设置配额.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!--
Each node in your cluster must have at least 1 GiB of memory.
-->
集群中每个节点至少有1 GiB的内存。
集群中每个节点至少有 1 GiB 的内存。
<!-- steps -->
@ -64,7 +53,6 @@ kubectl create namespace quota-mem-cpu-example
Here is the configuration file for a ResourceQuota object:
-->
## 创建 ResourceQuota
这里给出一个 ResourceQuota 对象的配置文件：
@ -74,17 +62,15 @@ Here is the configuration file for a ResourceQuota object:
<!--
Create the ResourceQuota:
-->
创建 ResourceQuota
```shell
kubectl create -f https://k8s.io/examples/admin/resource/quota-mem-cpu.yaml --namespace=quota-mem-cpu-example
kubectl apply -f https://k8s.io/examples/admin/resource/quota-mem-cpu.yaml --namespace=quota-mem-cpu-example
```
<!--
View detailed information about the ResourceQuota:
-->
查看 ResourceQuota 详情：
```shell
@ -100,7 +86,6 @@ The ResourceQuota places these requirements on the quota-mem-cpu-example namespa
* The CPU request total for all Containers must not exceed 1 cpu.
* The CPU limit total for all Containers must not exceed 2 cpu.
-->
ResourceQuota 在 quota-mem-cpu-example 命名空间中设置了如下要求：
* 每个容器必须有内存请求和限制，以及 CPU 请求和限制。
@ -114,28 +99,24 @@ ResourceQuota 在 quota-mem-cpu-example 命名空间中设置了如下要求：
Here is the configuration file for a Pod:
-->
## 创建 Pod
这里给出 Pod 的配置文件：
{{< codenew file="admin/resource/quota-mem-cpu-pod.yaml" >}}
<!--
Create the Pod:
-->
创建 Pod：
```shell
kubectl create -f https://k8s.io/examples/admin/resource/quota-mem-cpu-pod.yaml --namespace=quota-mem-cpu-example
kubectl apply -f https://k8s.io/examples/admin/resource/quota-mem-cpu-pod.yaml --namespace=quota-mem-cpu-example
```
<!--
Verify that the Pod's Container is running:
-->
检查下 Pod 中的容器在运行：
```
@ -145,7 +126,6 @@ kubectl get pod quota-mem-cpu-demo --namespace=quota-mem-cpu-example
<!--
Once again, view detailed information about the ResourceQuota:
-->
再查看 ResourceQuota 的详情：
```
@ -157,7 +137,6 @@ The output shows the quota along with how much of the quota has been used.
You can see that the memory and CPU requests and limits for your Pod do not
exceed the quota.
-->
输出结果显示了配额以及有多少配额已经被使用。你可以看到 Pod 的内存和 CPU 请求值及限制值没有超过配额。
```
@ -179,7 +158,6 @@ status:
Here is the configuration file for a second Pod:
-->
## 尝试创建第二个 Pod
这里给出了第二个 Pod 的配置文件：
@ -194,19 +172,20 @@ request exceeds the memory request quota. 600 MiB + 700 MiB > 1 GiB.
Attempt to create the Pod:
-->
配置文件中，你可以看到 Pod 的内存请求为700 MiB。请注意新的内存请求与已经使用的内存请求只和超过了内存请求的配额。600 MiB + 700 MiB > 1 GiB。
配置文件中，你可以看到 Pod 的内存请求为 700 MiB。
请注意新的内存请求与已经使用的内存请求只和超过了内存请求的配额。
600 MiB + 700 MiB > 1 GiB。
尝试创建 Pod：
```shell
kubectl create -f https://k8s.io/examples/admin/resource/quota-mem-cpu-pod-2.yaml --namespace=quota-mem-cpu-example
kubectl apply -f https://k8s.io/examples/admin/resource/quota-mem-cpu-pod-2.yaml --namespace=quota-mem-cpu-example
```
<!--
The second Pod does not get created. The output shows that creating the second Pod
would cause the memory request total to exceed the memory request quota.
-->
第二个 Pod 不能被创建成功。输出结果显示创建第二个 Pod 会导致内存请求总量超过内存请求配额。
```
@ -225,20 +204,20 @@ You can also restrict the totals for memory limit, cpu request, and cpu limit.
If you want to restrict individual Containers, instead of totals for all Containers, use a
[LimitRange](/docs/tasks/administer-cluster/memory-constraint-namespace/).
-->
## 讨论
如你在本练习中所见，你可以用 ResourceQuota 限制命名空间中所有容器的内存请求总量。同样你也可以限制内存限制总量、CPU 请求总量、CPU 限制总量。
如你在本练习中所见，你可以用 ResourceQuota 限制命名空间中所有容器的内存请求总量。
同样你也可以限制内存限制总量、CPU 请求总量、CPU 限制总量。
如果你想对单个容器而不是所有容器进行限制，就请使用 [LimitRange](/docs/tasks/administer-cluster/memory-constraint-namespace/)。
如果你想对单个容器而不是所有容器进行限制，就请使用
[LimitRange](/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)。
<!--
## Clean up
Delete your namespace:
-->
## 数据清理
## 清理
删除你的命名空间：
@ -246,57 +225,38 @@ Delete your namespace:
kubectl delete namespace quota-mem-cpu-example
```
## {{% heading "whatsnext" %}}
<!--
### For cluster administrators
* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/)
* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/cpu-default-namespace/)
* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/)
* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
* [Configure a Pod Quota for a Namespace](/docs/tasks/administer-cluster/quota-pod-namespace/)
* [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/)
-->
### 集群管理员参考
* [为命名空间配置默认内存请求和限制](/docs/tasks/administer-cluster/memory-default-namespace/)
* [为命名空间配置内存限制的最小值和最大值](/docs/tasks/administer-cluster/memory-constraint-namespace/)
* [为命名空间配置 CPU 限制的最小值和最大值](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
* [为命名空间配置内存和 CPU 配额](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)
* [为命名空间配置 Pod 配额](/docs/tasks/administer-cluster/quota-pod-namespace/)
* [为 API 对象配置配额](/docs/tasks/administer-cluster/quota-api-object/)
* [为命名空间配置默认内存请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
* [为命名空间配置内存限制的最小值和最大值](/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
* [为命名空间配置 CPU 限制的最小值和最大值](/zh/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
* [为命名空间配置内存和 CPU 配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
* [为命名空间配置 Pod 配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/)
* [为 API 对象配置配额](/zh/docs/tasks/administer-cluster/quota-api-object/)
<!--
### For app developers
* [Assign Memory Resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-memory-resource/)
* [Assign CPU Resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-cpu-resource/)
* [Configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/)
-->
### 应用开发者参考
* [为容器和 Pod 分配内存资源](/docs/tasks/configure-pod-container/assign-memory-resource/)
* [为容器和 Pod 分配CPU资源](/docs/tasks/configure-pod-container/assign-cpu-resource/)
* [为 Pod 配置 Service 数量](/docs/tasks/configure-pod-container/quality-service-pod/)
* [为容器和 Pod 分配内存资源](/zh/docs/tasks/configure-pod-container/assign-memory-resource/)
* [为容器和 Pod 分配CPU资源](/zh/docs/tasks/configure-pod-container/assign-cpu-resource/)
* [为 Pod 配置 Service 数量](/zh/docs/tasks/configure-pod-container/quality-service-pod/)

131
content/zh/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md
View File

@ -1,28 +1,34 @@
---
title: 配置命名空间下pod总数
title: 配置命名空间下 Pod 配额
content_type: task
weight: 60
---
<!-- overview -->
本文主要描述如何配置一个命名空间下可运行的pod总数。资源配额详细信息可查看：[资源配额](/docs/api-reference/v1.7/#resourcequota-v1-core)
。
<!--
This page shows how to set a quota for the total number of Pods that can run
in a namespace. You specify quotas in a
[ResourceQuota](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcequota-v1-core)
object.
-->
本文主要描述如何配置一个命名空间下可运行的 Pod 个数配额。
你可以使用
[ResourceQuota](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcequota-v1-core)
对象来配置配额。
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- steps -->
<!--
## Create a namespace
Create a namespace so that the resources you create in this exercise are
isolated from the rest of your cluster.
-->
## 创建一个命名空间
首先创建一个命名空间，这样可以将本次操作中创建的资源与集群其他资源隔离开来。
@ -31,25 +37,39 @@ weight: 60
kubectl create namespace quota-pod-example
```
## 创建资源配额
<!--
## Create a ResourceQuota
下面是一个资源配额的配置文件：
Here is the configuration file for a ResourceQuota object:
-->
## 创建 ResourceQuota
下面是一个 ResourceQuota 的配置文件：
{{< codenew file="admin/resource/quota-pod.yaml" >}}
创建这个资源配额：
<!-- 创建 ResourceQuota: -->
创建这个 ResourceQuota：
```shell
kubectl apply -f https://k8s.io/examples/admin/resource/quota-pod.yaml --namespace=quota-pod-example
```
<!--
View detailed information about the ResourceQuota:
-->
查看资源配额的详细信息：
```shell
kubectl get resourcequota pod-demo --namespace=quota-pod-example --output=yaml
```
从输出的信息我们可以看到，该命名空间下pod的配额是2个，目前创建的pods数为0，配额使用率为0。
<!--
The output shows that the namespace has a quota of two Pods, and that currently there are
no Pods; that is, none of the quota is used.
-->
从输出的信息我们可以看到，该命名空间下 Pod 的配额是 2 个，目前创建的 Pod 数为 0，
配额使用率为 0。
```yaml
spec:
@ -62,25 +82,40 @@ status:
pods: "0"
```
下面是一个Deployment的配置文件：
<!--
Here is the configuration file for a Deployment:
-->
下面是一个 Deployment 的配置文件：
{{< codenew file="admin/resource/quota-pod-deployment.yaml" >}}
在配置文件中， `replicas: 3` 告诉kubernetes尝试创建三个pods，且运行相同的应用。
<!--
In the configuration file, `replicas: 3` tells Kubernetes to attempt to create three Pods, all running the same application.
创建这个Deployment：
Create the Deployment:
-->
在配置文件中，`replicas: 3` 告诉 Kubernetes 尝试创建三个 Pods，且运行相同的应用。
创建这个 Deployment：
```shell
kubectl apply -f https://k8s.io/examples/admin/resource/quota-pod-deployment.yaml --namespace=quota-pod-example
```
查看Deployment的详细信息：
<!--
View detailed information about the Deployment:
-->
查看 Deployment 的详细信息：
```shell
kubectl get deployment pod-quota-demo --namespace=quota-pod-example --output=yaml
```
从输出的信息我们可以看到，尽管尝试创建三个pod，但是由于配额的限制，只有两个pod能被成功创建。
<!--
The output shows that even though the Deployment specifies three replicas, only two
Pods were created because of the quota.
-->
从输出的信息我们可以看到，尽管尝试创建三个 Pod，但是由于配额的限制，只有两个 Pod 能被成功创建。
```yaml
spec:
@ -95,6 +130,11 @@ lastUpdateTime: 2017-07-07T20:57:05Z
exceeded quota: pod-demo, requested: pods=1, used: pods=2, limited: pods=2'
```
<!--
## Clean up
Delete your namespace:
-->
## 清理
删除命名空间：
@ -103,36 +143,37 @@ lastUpdateTime: 2017-07-07T20:57:05Z
kubectl delete namespace quota-pod-example
```
## {{% heading "whatsnext" %}}
<!--
### For cluster administrators
### 对于集群管理
* [配置命名空间下，内存默认的request值和limit值](/docs/tasks/administer-cluster/memory-default-namespace/)
* [配置命名空间下，CPU默认的request值和limit值](/docs/tasks/administer-cluster/cpu-default-namespace/)
* [配置命名空间下，内存的最小值和最大值](/docs/tasks/administer-cluster/memory-constraint-namespace/)
* [配置命名空间下，CPU的最小值和最大值](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
* [配置命名空间下，内存和CPU的配额](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)
* [配置命名空间下，API对象的配额](/docs/tasks/administer-cluster/quota-api-object/)
### 对于应用开发
* [给容器和pod分配内存资源](/docs/tasks/configure-pod-container/assign-memory-resource/)
* [给容器和pod分配CPU资源](/docs/tasks/configure-pod-container/assign-cpu-resource/)
* [配置pod的QoS](/docs/tasks/configure-pod-container/quality-service-pod/)
* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)
* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
* [Configure Memory and CPU Quotas for a Namespace](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
* [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/)
-->
### 集群管理人员参考
* [为命名空间配置默认的内存请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
* [为命名空间配置默认的的 CPU 请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)
* [为命名空间配置内存的最小值和最大值约束](/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
* [为命名空间配置 CPU 的最小值和最大值约束](/zh/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
* [为命名空间配置内存和 CPU 配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
* [为 API 对象的设置配额](/zh/docs/tasks/administer-cluster/quota-api-object/)
<!--
### For app developers
* [Assign Memory Resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-memory-resource/)
* [Assign CPU Resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-cpu-resource/)
* [Configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/)
-->
### 应用开发人员参考
* [为容器和 Pod 分配内存资源](/zh/docs/tasks/configure-pod-container/assign-memory-resource/)
* [给容器和 Pod 分配 CPU 资源](/zh/docs/tasks/configure-pod-container/assign-cpu-resource/)
* [配置 Pod 的服务质量](/zh/docs/tasks/configure-pod-container/quality-service-pod/)

168
content/zh/docs/tasks/administer-cluster/running-cloud-controller.md
View File

@ -1,36 +1,37 @@
---
reviewers:
- luxas
- thockin
- wlan0
title: Kubernetes 云管理控制器
content_type: concept
---
<!--
---
reviewers:
- luxas
- thockin
- wlan0
title: Kubernetes Cloud Controller Manager
content_type: concept
---
-->
<!-- overview -->
{{< feature-state state="beta" >}}
{{< feature-state state="beta" for_k8s_version="v1.11" >}}
<!--
Kubernetes v1.6 introduced a new binary called `cloud-controller-manager`. `cloud-controller-manager` is a daemon that embeds cloud-specific control loops. These cloud-specific control loops were originally in the `kube-controller-manager`. Since cloud providers develop and release at a different pace compared to the Kubernetes project, abstracting the provider-specific code to the `cloud-controller-manager` binary allows cloud vendors to evolve independently from the core Kubernetes code.
The `cloud-controller-manager` can be linked to any cloud provider that satisfies [cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go). For backwards compatibility, the [cloud-controller-manager](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager) provided in the core Kubernetes project uses the same cloud libraries as `kube-controller-manager`. Cloud providers already supported in Kubernetes core are expected to use the in-tree cloud-controller-manager to transition out of Kubernetes core. In future Kubernetes releases, all cloud controller managers will be developed outside of the core Kubernetes project managed by sig leads or cloud vendors.
Since cloud providers develop and release at a different pace compared to the Kubernetes project, abstracting the provider-specific code to the {{< glossary_tooltip text="`cloud-controller-manager`" term_id="cloud-controller-manager" >}} binary allows cloud vendors to evolve independently from the core Kubernetes code.
-->
Kubernetes v1.6 包含一个新的二进制文件，叫做 `cloud-controller-manager`。`cloud-controller-manager` 是一个嵌入了特定云服务控制循环逻辑的守护进程。这些特定云服务控制循环逻辑最初存在于 `kube-controller-manager` 中。由于云服务提供商开发和发布的速度与 Kubernetes 项目不同，将服务提供商专用代码从 `cloud-controller-manager` 二进制中抽象出来有助于云服务厂商在 Kubernetes 核心代码之外独立进行开发。
`cloud-controller-manager` 可以被链接到任何满足 [cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go) 约束的云服务提供商。为了兼容旧版本，Kubernetes 核心项目中提供的 [cloud-controller-manager](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager) 使用和 `kube-controller-manager` 相同的云服务类库。已经在 Kubernetes 核心项目中支持的云服务提供商预计将通过使用 in-tree 的 cloud-controller-manager 过渡到 Kubernetes 核心之外。在将来的 Kubernetes 发布中，所有的云管理控制器将在 Kubernetes 核心项目之外，由 sig 领导者或者云服务厂商进行开发。
由于云驱动的开发和发布的步调与 Kubernetes 项目不同，将服务提供商专用代码抽象到
{{< glossary_tooltip text="`cloud-controller-manager`" term_id="cloud-controller-manager" >}}
二进制中有助于云服务厂商在 Kubernetes 核心代码之外独立进行开发。
<!--
The `cloud-controller-manager` can be linked to any cloud provider that satisfies [cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go). For backwards compatibility, the [cloud-controller-manager](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager) provided in the core Kubernetes project uses the same cloud libraries as `kube-controller-manager`. Cloud providers already supported in Kubernetes core are expected to use the in-tree cloud-controller-manager to transition out of Kubernetes core.
-->
`cloud-controller-manager` 可以被链接到任何满足
[cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go)
约束的云服务提供商。为了兼容旧版本，Kubernetes 核心项目中提供的
[cloud-controller-manager](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager)
使用和 `kube-controller-manager` 相同的云服务类库。
已经在 Kubernetes 核心项目中支持的云服务提供商预计将通过使用 in-tree 的 cloud-controller-manager
过渡为非 Kubernetes 核心代码。
<!-- body -->
@ -49,52 +50,68 @@ Every cloud has their own set of requirements for running their own cloud provid
### 需求
每个云服务都有一套各自的需求用于系统平台的集成，这不应与运行 `kube-controller-manager` 的需求有太大差异。作为经验法则，你需要：
每个云服务都有一套各自的需求用于系统平台的集成，这不应与运行
`kube-controller-manager` 的需求有太大差异。作为经验法则，你需要：
* 云服务认证 / 授权：您的云服务可能需要使用令牌或者 IAM 规则以允许对其 API 的访问
* kubernetes 认证 / 授权：cloud-controller-manager 可能需要 RBAC 规则以访问 kubernetes apiserver
* 高可用：类似于 kube-controller-manager，您可能希望通过主节点选举（默认开启）配置一个高可用的云管理控制器。
* 云服务认证/授权：你的云服务可能需要使用令牌或者 IAM 规则以允许对其 API 的访问
* kubernetes 认证/授权：cloud-controller-manager 可能需要 RBAC 规则以访问 kubernetes apiserver
* 高可用：类似于 kube-controller-manager，你可能希望通过主节点选举（默认开启）配置一个高可用的云管理控制器。
<!--
### Running cloud-controller-manager
Successfully running cloud-controller-manager requires some changes to your cluster configuration.
-->
### 运行云管理控制器
你需要对集群配置做适当的修改以成功地运行云管理控制器：
<!--
* `kube-apiserver` and `kube-controller-manager` MUST NOT specify the `--cloud-provider` flag. This ensures that it does not run any cloud specific loops that would be run by cloud controller manager. In the future, this flag will be deprecated and removed.
* `kubelet` must run with `--cloud-provider=external`. This is to ensure that the kubelet is aware that it must be initialized by the cloud controller manager before it is scheduled any work.
-->
* 一定不要为 `kube-apiserver` 和 `kube-controller-manager` 指定 `--cloud-provider` 标志。
这将保证它们不会运行任何云服务专用循环逻辑，这将会由云管理控制器运行。未来这个标记将被废弃并去除。
* `kubelet` 必须使用 `--cloud-provider=external` 运行。
这是为了保证让 kubelet 知道在执行任何任务前，它必须被云管理控制器初始化。
<!--
Keep in mind that setting up your cluster to use cloud controller manager will change your cluster behaviour in a few ways:
-->
请记住，设置群集使用云管理控制器将用多种方式更改群集行为：
<!--
* kubelets specifying `--cloud-provider=external` will add a taint `node.cloudprovider.kubernetes.io/uninitialized` with an effect `NoSchedule` during initialization. This marks the node as needing a second initialization from an external controller before it can be scheduled work. Note that in the event that cloud controller manager is not available, new nodes in the cluster will be left unschedulable. The taint is important since the scheduler may require cloud specific information about nodes such as their region or type (high cpu, gpu, high memory, spot instance, etc).
-->
* 指定了 `--cloud-provider=external` 的 kubelet 将被添加一个 `node.cloudprovider.kubernetes.io/uninitialized`
的污点，导致其在初始化过程中不可调度（`NoSchedule`）。
这将标记该节点在能够正常调度前，需要外部的控制器进行二次初始化。
请注意，如果云管理控制器不可用，集群中的新节点会一直处于不可调度的状态。
这个污点很重要，因为调度器可能需要关于节点的云服务特定的信息，比如他们的区域或类型
（高端 CPU、GPU 支持、内存较大、临时实例等）。
<!--
* cloud information about nodes in the cluster will no longer be retrieved using local metadata, but instead all API calls to retrieve node information will go through cloud controller manager. This may mean you can restrict access to your cloud API on the kubelets for better security. For larger clusters you may want to consider if cloud controller manager will hit rate limits since it is now responsible for almost all API calls to your cloud from within the cluster.
-->
* 集群中节点的云服务信息将不再能够从本地元数据中获取，取而代之的是所有获取节点信息的
API 调用都将通过云管理控制器。这意味着你可以通过限制到 kubelet 云服务 API 的访问来提升安全性。
在更大的集群中你可能需要考虑云管理控制器是否会遇到速率限制，
因为它现在负责集群中几乎所有到云服务的 API 调用。
As of v1.8, cloud controller manager can implement:
<!--
Cloud controller manager can implement:
* node controller - responsible for updating kubernetes nodes using cloud APIs and deleting kubernetes nodes that were deleted on your cloud.
* service controller - responsible for loadbalancers on your cloud against services of type LoadBalancer.
* route controller - responsible for setting up network routes on your cloud
* any other features you would like to implement if you are running an out-of-tree provider.
-->
### 运行云管理控制器
云管理控制器可以实现：
您需要对集群配置做适当的修改以成功地运行云管理控制器：
* 一定不要为 `kube-apiserver` 和 `kube-controller-manager` 指定 `--cloud-provider` 标志。这将保证它们不会运行任何云服务专用循环逻辑，这将会由云管理控制器运行。未来这个标记将被废弃并去除。
* `kubelet` 必须使用 `--cloud-provider=external` 运行。这是为了保证让 kubelet 知道在执行任何任务前，它必须被云管理控制器初始化。
请记住，设置群集使用云管理控制器将用多种方式更改群集行为：
* 指定了 `--cloud-provider=external` 的 kubelet 将被添加一个 `node.cloudprovider.kubernetes.io/uninitialized` 的污点，导致其在初始化过程中不可调度（`NoSchedule`）。这将标记该节点在能够正常调度前，需要外部的控制器进行二次初始化。请注意，如果云管理控制器不可用，集群中的新节点会一直处于不可调度的状态。这个污点很重要，因为调度器可能需要关于节点的云服务特定的信息，比如他们的区域或类型（high cpu, gpu, high memory, spot instance 等）。
* 集群中节点的云服务信息将不再能够从本地元数据中获取，取而代之的是所有获取节点信息的 API 调用都将通过云管理控制器。这意味着你可以通过限制到 kubelet 云服务 API 的访问来提升安全性。在更大的集群中您可能需要考虑云管理控制器是否会遇到速率限制，因为它现在负责集群中几乎所有到云服务的 API 调用。
对于 v1.8 版本，云管理控制器可以实现：
* node 控制器 - 负责使用云服务 API 更新 kubernetes 节点并删除在云服务上已经删除的 kubernetes 节点。
* service 控制器 - 负责在云服务上为类型为 LoadBalancer 的 service 提供负载均衡器。
* route 控制器 - 负责在云服务上配置网络路由。
* 如果您使用的是 out-of-tree 提供商，请按需实现其余任意特性。
* 节点控制器 - 负责使用云服务 API 更新 kubernetes 节点并删除在云服务上已经删除的 kubernetes 节点。
* 服务控制器 - 负责在云服务上为类型为 LoadBalancer 的 service 提供负载均衡器。
* 路由控制器 - 负责在云服务上配置网络路由。
* 如果你使用的是 out-of-tree 提供商，请按需实现其余任意特性。
<!--
## Examples
@ -102,28 +119,23 @@ As of v1.8, cloud controller manager can implement:
If you are using a cloud that is currently supported in Kubernetes core and would like to adopt cloud controller manager, see the [cloud controller manager in kubernetes core](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager).
For cloud controller managers not in Kubernetes core, you can find the respective projects in repos maintained by cloud vendors or sig leads.
* [DigitalOcean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
* [keepalived](https://github.com/munnerz/keepalived-cloud-provider)
* [Oracle Cloud Infrastructure](https://github.com/oracle/oci-cloud-controller-manager)
* [Rancher](https://github.com/rancher/rancher-cloud-controller-manager)
For providers already in Kubernetes core, you can run the in-tree cloud controller manager as a Daemonset in your cluster, use the following as a guideline:
{{< codenew file="admin/cloud/ccm-example.yaml" >}}
-->
## 示例
如果当前 Kubernetes 内核支持您使用的云服务，并且想要采用云管理控制器，请参见 [kubernetes 内核中的云管理控制器](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager)。
如果当前 Kubernetes 内核支持你使用的云服务，并且想要采用云管理控制器，请参见
[kubernetes 内核中的云管理控制器](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager)。
对于不在 Kubernetes 内核中的云管理控制器，您可以在云服务厂商或 sig 领导者的源中找到对应的项目。
对于不在 Kubernetes 核心代码库中的云管理控制器，你可以在云服务厂商或 SIG 领导者的源中找到对应的项目。
* [DigitalOcean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
* [keepalived](https://github.com/munnerz/keepalived-cloud-provider)
* [Oracle Cloud Infrastructure](https://github.com/oracle/oci-cloud-controller-manager)
* [Rancher](https://github.com/rancher/rancher-cloud-controller-manager)
对于已经存在于 Kubernetes 内核中的提供商，您可以在集群中将 in-tree 云管理控制器作为守护进程运行。请使用如下指南：
<!--
For providers already in Kubernetes core, you can run the in-tree cloud controller manager as a Daemonset in your cluster, use the following as a guideline:
-->
对于已经存在于 Kubernetes 内核中的提供商，你可以在集群中将 in-tree 云管理控制器作为守护进程运行。请使用如下指南：
{{< codenew file="admin/cloud/ccm-example.yaml" >}}
@ -131,49 +143,59 @@ For providers already in Kubernetes core, you can run the in-tree cloud controll
## Limitations
Running cloud controller manager comes with a few possible limitations. Although these limitations are being addressed in upcoming releases, it's important that you are aware of these limitations for production workloads.
### Support for Volumes
Cloud controller manager does not implement any of the volume controllers found in `kube-controller-manager` as the volume integrations also require coordination with kubelets. As we evolve CSI (container storage interface) and add stronger support for flex volume plugins, necessary support will be added to cloud controller manager so that clouds can fully integrate with volumes. Learn more about out-of-tree CSI volume plugins [here](https://github.com/kubernetes/features/issues/178).
### Scalability
In the previous architecture for cloud providers, we relied on kubelets using a local metadata service to retrieve node information about itself. With this new architecture, we now fully rely on the cloud controller managers to retrieve information for all nodes. For very larger clusters, you should consider possible bottle necks such as resource requirements and API rate limiting.
-->
## 限制
运行云管理控制器会有一些可能的限制。虽然以后的版本将处理这些限制，但是知道这些生产负载的限制很重要。
<!--
### Support for Volumes
Cloud controller manager does not implement any of the volume controllers found in `kube-controller-manager` as the volume integrations also require coordination with kubelets. As we evolve CSI (container storage interface) and add stronger support for flex volume plugins, necessary support will be added to cloud controller manager so that clouds can fully integrate with volumes. Learn more about out-of-tree CSI volume plugins [here](https://github.com/kubernetes/features/issues/178).
-->
### 对 Volume 的支持
云管理控制器未实现 `kube-controller-manager` 中的任何 volume 控制器，因为和 volume 的集成还需要与 kubelet 协作。由于我们引入了 CSI (容器存储接口，container storage interface) 并对弹性 volume 插件添加了更强大的支持，云管理控制器将添加必要的支持，以使云服务同 volume 更好的集成。请在 [这里](https://github.com/kubernetes/features/issues/178) 了解更多关于 out-of-tree CSI volume 插件的信息。
<!--
### Scalability
In the previous architecture for cloud providers, we relied on kubelets using a local metadata service to retrieve node information about itself. With this new architecture, we now fully rely on the cloud controller managers to retrieve information for all nodes. For very larger clusters, you should consider possible bottle necks such as resource requirements and API rate limiting.
-->
### 可扩展性
在以前为云服务提供商提供的架构中，我们依赖 kubelet 的本地元数据服务来获取关于它本身的节点信息。通过这个新的架构，现在我们完全依赖云管理控制器来获取所有节点的信息。对于非常大的集群，您需要考虑可能的瓶颈，例如资源需求和 API 速率限制。
在以前为云服务提供商提供的架构中，我们依赖 kubelet 的本地元数据服务来获取关于它本身的节点信息。通过这个新的架构，现在我们完全依赖云管理控制器来获取所有节点的信息。对于非常大的集群，你需要考虑可能的瓶颈，例如资源需求和 API 速率限制。
<!--
### Chicken and Egg
The goal of the cloud controller manager project is to decouple development of cloud features from the core Kubernetes project. Unfortunately, many aspects of the Kubernetes project has assumptions that cloud provider features are tightly integrated into the project. As a result, adopting this new architecture can create several situations where a request is being made for information from a cloud provider, but the cloud controller manager may not be able to return that information without the original request being complete.
A good example of this is the TLS bootstrapping feature in the Kubelet. Currently, TLS bootstrapping assumes that the Kubelet has the ability to ask the cloud provider (or a local metadata service) for all its address types (private, public, etc) but cloud controller manager cannot set a node's address types without being initialized in the first place which requires that the kubelet has TLS certificates to communicate with the apiserver.
As this initiative evolves, changes will be made to address these issues in upcoming releases.
## Developing your own Cloud Controller Manager
To build and develop your own cloud controller manager, read the [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager.md) doc.
-->
### 鸡和蛋的问题
云管理控制器的目标是将云服务特性的开发从 Kubernetes 核心项目中解耦。不幸的是，Kubernetes 项目的许多方面都假设云服务提供商的特性同项目紧密结合。因此，这种新架构的采用可能导致某些场景下，当一个请求需要从云服务提供商获取信息时，在该请求没有完成的情况下云管理控制器不能返回那些信息。
云管理控制器的目标是将云服务特性的开发从 Kubernetes 核心项目中解耦。
不幸的是，Kubernetes 项目的许多方面都假设云服务提供商的特性同项目紧密结合。
因此，这种新架构的采用可能导致某些场景下，当一个请求需要从云服务提供商获取信息时，
在该请求没有完成的情况下云管理控制器不能返回那些信息。
Kubelet 中的 TLS 引导特性是一个很好的例子。目前，TLS 引导认为 Kubelet 有能力从云提供商（或本地元数据服务）获取所有的地址类型（私有、公用等），但在被初始化之前，云管理控制器不能设置节点地址类型，而这需要 kubelet 拥有 TLS 证书以和 apiserver 通信。
<!--
A good example of this is the TLS bootstrapping feature in the Kubelet. Currently, TLS bootstrapping assumes that the Kubelet has the ability to ask the cloud provider (or a local metadata service) for all its address types (private, public, etc) but cloud controller manager cannot set a node's address types without being initialized in the first place which requires that the kubelet has TLS certificates to communicate with the apiserver.
随着这种措施的演进，将来的发行版中将作出改变来解决这些问题。
As this initiative evolves, changes will be made to address these issues in upcoming releases.
-->
Kubelet 中的 TLS 引导特性是一个很好的例子。
目前，TLS 引导认为 kubelet 有能力从云提供商（或本地元数据服务）获取所有的地址类型（私有、公用等），
但在被初始化之前，云管理控制器不能设置节点地址类型，而这需要 kubelet 拥有
TLS 证书以和 API 服务器通信。
## 开发自己的云管理控制器
随着整个动议的演进，将来的发行版中将作出改变来解决这些问题。
要构建和开发您自己的云管理控制器，请阅读 [开发云管理控制器](/docs/tasks/administer-cluster/developing-cloud-controller-manager.md) 文档。
## {{% heading "whatsnext" %}}
<!--
To build and develop your own cloud controller manager, read the [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager.md) doc.
-->
要构建和开发你自己的云管理控制器，请阅读
[开发云管理控制器](/zh/docs/tasks/administer-cluster/developing-cloud-controller-manager/)
文档。

189
content/zh/docs/tasks/administer-cluster/securing-a-cluster.md
View File

@ -1,14 +1,8 @@
---
reviewers:
- smarterclayton
- liggitt
- ericchiang
- destijl
title: 集群安全
title: 保护集群安全
content_type: task
---
<!--
---
reviewers:
- smarterclayton
- liggitt
@ -16,7 +10,6 @@ reviewers:
- destijl
title: Securing a Cluster
content_type: task
---
-->
<!-- overview -->
@ -27,15 +20,10 @@ and provides recommendations on overall security.
-->
本文档涉及与保护集群免受意外或恶意访问有关的主题，并对总体安全性提出建议。
## {{% heading "prerequisites" %}}
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- steps -->
<!--
@ -57,7 +45,7 @@ the cluster components. Note that some components and installation methods may e
HTTP and administrators should familiarize themselves with the settings of each component to identify
potentially unsecured traffic.
-->
### 为 API 交互提供传输层安全 （TLS）
### 为所有 API 交互使用传输层安全 （TLS）
Kubernetes 期望集群中所有的 API 通信在默认情况下都使用 TLS 加密，大多数安装方法也允许创建所需的证书并且分发到集群组件中。请注意，某些组件和安装方法可能使用 HTTP 来访问本地端口， 管理员应该熟悉每个组件的设置，以识别潜在的不安全的流量。
@ -76,11 +64,15 @@ Consult the [authentication reference document](/docs/reference/access-authn-aut
-->
### API 认证
安装集群时，选择一个 API 服务器的身份验证机制，去使用与之匹配的公共访问模式。例如，小型的单用户集群可能希望使用简单的证书或静态承载令牌方法。更大的集群则可能希望整合现有的、OIDC、LDAP 等允许用户分组的服务器。
安装集群时，选择一个 API 服务器的身份验证机制，去使用与之匹配的公共访问模式。
例如，小型的单用户集群可能希望使用简单的证书或静态承载令牌方法。
更大的集群则可能希望整合现有的、OIDC、LDAP 等允许用户分组的服务器。
所有 API 客户端都必须经过身份验证，即使它是基础设施的一部分，比如节点、代理、调度程序和卷插件。这些客户端通常使用 [服务帐户](/docs/reference/access-authn-authz/service-accounts-admin/) 或 X509 客户端证书，并在集群启动时自动创建或是作为集群安装的一部分进行设置。
所有 API 客户端都必须经过身份验证，即使它是基础设施的一部分，比如节点、代理、调度程序和卷插件。
这些客户端通常使用 [服务帐户](/zh/docs/reference/access-authn-authz/service-accounts-admin/)
或 X509 客户端证书，并在集群启动时自动创建或是作为集群安装的一部分进行设置。
如果您希望获取更多信息，请参考 [认证参考文档](/docs/reference/access-authn-authz/authentication/)。
如果你希望获取更多信息，请参考[认证参考文档](/zh/docs/reference/access-authn-authz/authentication/)。
<!--
### API Authorization
@ -92,11 +84,28 @@ resources (pods, services, nodes) and can be namespace or cluster scoped. A set
roles are provided that offer reasonable default separation of responsibility depending on what
actions a client might want to perform. It is recommended that you use the [Node](/docs/reference/access-authn-authz/node/) and [RBAC](/docs/reference/access-authn-authz/rbac/) authorizers together, in combination with the
[NodeRestriction](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) admission plugin.
-->
### API 授权
一旦通过身份认证，每个 API 的调用都将通过鉴权检查。
Kubernetes 集成[基于角色的访问控制（RBAC）](/zh/docs/reference/access-authn-authz/rbac/)组件，
将传入的用户或组与一组绑定到角色的权限匹配。
这些权限将动作（get，create，delete）和资源（pod，service, node）在命名空间或者集群范围内结合起来，
根据客户可能希望执行的操作，提供了一组提供合理的违约责任分离的外包角色。
建议你将[节点](/zh/docs/reference/access-authn-authz/node/) 和
[RBAC](/zh/docs/reference/access-authn-authz/rbac/) 一起作为授权者，再与
[NodeRestriction](/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction)
准入插件结合使用。
<!--
As with authentication, simple and broad roles may be appropriate for smaller clusters, but as
more users interact with the cluster, it may become necessary to separate teams into separate
namespaces with more limited roles.
-->
与身份验证一样，简单而广泛的角色可能适合于较小的集群，但是随着更多的用户与集群交互，
可能需要将团队划分成有更多角色限制的单独的命名空间。
<!--
With authorization, it is important to understand how updates on one object may cause actions in
other places. For instance, a user may not be able to create pods directly, but allowing them to
create a deployment, which creates pods on their behalf, will let them create those pods
@ -107,15 +116,14 @@ to prevent accidental escalation. You can make roles specific to your use case i
Consult the [authorization reference section](/docs/reference/access-authn-authz/authorization/) for more information.
-->
### API 授权
就鉴权而言，理解怎么样更新一个对象可能导致在其它地方的发生什么样的行为是非常重要的。
例如，用户可能不能直接创建 Pod，但允许他们通过创建一个 Deployment 来创建这些 Pod，
这将让他们间接创建这些 Pod。
同样地，从 API 删除一个节点将导致调度到这些节点上的 Pod 被中止，并在其他节点上重新创建。
原生的角色设计代表了灵活性和常见用例之间的平衡，但有限制的角色应该仔细审查，
以防止意外升级。如果外包角色不满足你的需求，则可以为用例指定特定的角色。
一旦使用授权，每个 API 的调用都将通过授权检查。Kubernetes 集成 [基于访问控制（RBAC）](/docs/reference/access-authn-authz/rbac/) 的组件，将传入的用户或组与一组绑定到角色的权限匹配。这些权限将动作（get，create，delete）和资源（pod，service, node）在命名空间或者集群范围内结合起来，根据客户可能希望执行的操作，提供了一组提供合理的违约责任分离的外包角色。建议您将[节点](/docs/reference/access-authn-authz/node/) 和 [RBAC](/docs/reference/access-authn-authz/rbac/) 一起作为授权者，再与 [NodeRestriction](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) 准入插件结合使用。
与身份验证一样，简单而广泛的角色可能适合于较小的集群，但是随着更多的用户与集群交互，可能需要将团队划分成有更多角色限制的单独的命名空间。
使用授权时，理解怎么样更新一个对象可能导致在其它地方的发生什么样的行为是非常重要的。例如，用户可能不能直接创建 pod，但允许他们通过创建一个 deployment 来创建这些 pod，这将让他们间接创建这些 pod。同样地，从 API 删除一个节点将导致调度到这些节点上的 pod 被中止，并在其他节点上重新创建。外包角色代表了灵活性和常见用例之间的平衡，但有限制的角色应该仔细审查，以防止意外升级。如果外包角色不满足您的需求，则可以为用例指定特定的角色。
如果您希望获取更多信息，请参考 [授权参考部分](/docs/reference/access-authn-authz/authorization/)。
如果你希望获取更多信息，请参阅[鉴权参考](/zh/docs/reference/access-authn-authz/authorization/)。
<!--
## Controlling access to the Kubelet
@ -128,11 +136,13 @@ Consult the [Kubelet authentication/authorization reference](/docs/admin/kubelet
-->
## 控制对 Kubelet 的访问
Kubelet 公开 HTTPS 端点，这些端点授予节点和容器强大的控制权。默认情况下，Kubelet 允许对此 API 进行未经身份验证的访问。
Kubelet 公开 HTTPS 端点，这些端点授予节点和容器强大的控制权。
默认情况下，Kubelet 允许对此 API 进行未经身份验证的访问。
生产级别的集群应启用 Kubelet 身份验证和授权。
如果您希望获取更多信息，请参考 [Kubelet 身份验证 / 授权参考](/docs/admin/kubelet-authentication-authorization)。
如果你希望获取更多信息，请参考
[Kubelet 身份验证/授权参考](/zh/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/)。
<!--
## Controlling the capabilities of a workload or user at runtime
@ -143,7 +153,8 @@ cluster, themselves, and other resources.
-->
## 控制运行时负载或用户的能力
Kubernetes 中的授权故意设置为了高层级，它侧重于对资源的粗行为。更强大的控制是以通过用例限制这些对象如何作用于集群、自身和其他资源上的**策略**存在的。
Kubernetes 中的授权故意设置为了高层级，它侧重于对资源的粗粒度行为。
更强大的控制是以通过用例限制这些对象如何作用于集群、自身和其他资源上的**策略**存在的。
<!--
### Limiting resource usage on a cluster
@ -159,10 +170,14 @@ reserved resources like memory, or to provide default limits when none are speci
-->
### 限制集群上的资源使用
[资源配额](/docs/concepts/policy/resource-quotas/)限制了授予命名空间的资源的数量或容量。这通常用于限制命名空间可以分配的 CPU、内存或持久磁盘的数量，但也可以控制每个命名空间中有多少个 pod、服务或卷的存在。
[限制范围](/docs/tasks/administer-cluster/memory-default-namespace/)限制了上述某些资源的最大值或者最小值，以防止用户使用类似内存这样的通用保留资源时请求不合理的过高或过低的值，或者在没有指定的情况下提供默认限制。
[资源配额](/zh/docs/concepts/policy/resource-quotas/)
限制了授予命名空间的资源的数量或容量。
这通常用于限制命名空间可以分配的 CPU、内存或持久磁盘的数量，但也可以控制
每个命名空间中有多少个 Pod、服务或卷的存在。
[限制范围](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)限制
上述某些资源的最大值或者最小值，以防止用户使用类似内存这样的通用保留资源时请求
不合理的过高或过低的值，或者在没有指定的情况下提供默认限制。
<!--
### Controlling what privileges containers run with
@ -172,7 +187,17 @@ that allows it to request access to running as a specific Linux user on a node (
access to run privileged or access the host network, and other controls that would otherwise
allow it to run unfettered on a hosting node. [Pod security policies](/docs/concepts/policy/pod-security-policy/)
can limit which users or service accounts can provide dangerous security context settings. For example, pod security policies can limit volume mounts, especially `hostPath`, which are aspects of a pod that should be controlled.
-->
### 控制容器运行的特权
Pod 定义包含了一个[安全上下文](/zh/docs/tasks/configure-pod-container/security-context/)，
用于描述允许它请求访问某个节点上的特定 Linux 用户（如 root）、获得特权或访问主机网络、
以及允许它在主机节点上不受约束地运行的其它控件。
[Pod 安全策略](/zh/docs/concepts/policy/pod-security-policy/)
可以限制哪些用户或服务帐户可以提供危险的安全上下文设置。
例如，Pod 的安全策略可以限制卷挂载，尤其是 `hostpath`，这些都是 Pod 应该控制的一些方面。
<!--
Generally, most application workloads need limited access to host resources so they can
successfully run as a root process (uid 0) without access to host information. However,
considering the privileges associated with the root user, you should write application
@ -180,11 +205,10 @@ containers to run as a non-root user. Similarly, administrators who wish to prev
client applications from escaping their containers should use a restrictive pod security
policy.
-->
### 控制容器运行的特权
pod 定义包含了一个[安全上下文](/docs/tasks/configure-pod-container/security-context/)，用于描述允许它请求访问某个节点上的特定 Linux 用户（如 root）、获得特权或访问主机网络、以及允许它在主机节点上不受约束地运行的其它控件。[Pod 安全策略](/docs/concepts/policy/pod-security-policy/)可以限制哪些用户或服务帐户可以提供危险的安全上下文设置。例如，pod 的安全策略可以限制卷挂载，尤其是 `hostpath`，这些都是 pod 应该控制的一些方面。
一般来说，大多数应用程序需要限制对主机资源的访问，他们可以在不能访问主机信息的情况下成功以根进程（UID 0）运行。但是，考虑到与 root 用户相关的特权，在编写应用程序容器时，您应该使用非 root 用户运行。类似地，希望阻止客户端应用程序逃避其容器的管理员，应该使用限制性的 pod 安全策略。
一般来说，大多数应用程序需要限制对主机资源的访问，
他们可以在不能访问主机信息的情况下成功以根进程（UID 0）运行。
但是，考虑到与 root 用户相关的特权，在编写应用程序容器时，你应该使用非 root 用户运行。
类似地，希望阻止客户端应用程序逃避其容器的管理员，应该使用限制性的 pod 安全策略。
<!--
### Restricting network access
@ -193,7 +217,15 @@ The [network policies](/docs/tasks/administer-cluster/declare-network-policy/) f
allows application authors to restrict which pods in other namespaces may access pods and ports
within their namespaces. Many of the supported [Kubernetes networking providers](/docs/concepts/cluster-administration/networking/)
now respect network policy.
-->
### 限制网络访问
基于命名空间的[网络策略](/zh/docs/tasks/administer-cluster/declare-network-policy/)
允许应用程序作者限制其它命名空间中的哪些 Pod 可以访问它们命名空间内的 Pod 和端口。
现在已经有许多支持网络策略的
[Kubernetes 网络供应商](/zh/docs/concepts/cluster-administration/networking/)。
<!--
Quota and limit ranges can also be used to control whether users may request node ports or
load balanced services, which on many clusters can control whether those users applications
are visible outside of the cluster.
@ -202,13 +234,11 @@ Additional protections may be available that control network rules on a per plug
environment basis, such as per-node firewalls, physically separating cluster nodes to
prevent cross talk, or advanced networking policy.
-->
### 限制网络访问
对于可以控制用户的应用程序是否在集群之外可见的许多集群，配额和限制范围也可用于
控制用户是否可以请求节点端口或负载均衡服务。
基于命名空间的[网络策略](/docs/tasks/administer-cluster/declare-network-policy/)允许应用程序作者限制其它命名空间中的哪些 pod 可以访问它们命名空间内的 pod 和端口。现在已经有许多支持网络策略的 [Kubernetes 网络供应商](/docs/concepts/cluster-administration/networking/)。
对于可以控制用户的应用程序是否在集群之外可见的许多集群，配额和限制范围也可用于控制用户是否可以请求节点端口或负载均衡服务。
在插件或者环境基础上控制网络规则可以增加额外的保护措施，比如节点防火墙、物理分离群集节点以防止串扰、或者高级的网络策略。
在插件或者环境基础上控制网络规则可以增加额外的保护措施，比如节点防火墙、物理分离
群集节点以防止串扰、或者高级的网络策略。
<!--
### Restricting cloud metadata API access
@ -224,9 +254,14 @@ to the metadata API, and avoid using provisioning data to deliver secrets.
-->
### 限制云 metadata API 访问
云平台（AWS, Azure, GCE 等）经常讲 metadate 本地服务暴露给实例。默认情况下，这些 API 可由运行在实例上的 pod 访问，并且可以包含该云节点的凭据或配置数据（如 kubelet 凭据）。这些凭据可以用于在集群内升级或在同一账户下升级到其他云服务。
云平台（AWS, Azure, GCE 等）经常讲 metadate 本地服务暴露给实例。
默认情况下，这些 API 可由运行在实例上的 Pod 访问，并且可以包含
该云节点的凭据或配置数据（如 kubelet 凭据）。
这些凭据可以用于在集群内升级或在同一账户下升级到其他云服务。
在云平台上运行 Kubernetes 时，限制对实例凭据的权限，使用[网络策略](/docs/tasks/administer-cluster/declare-network-policy/)限制对 metadate API 的 pod 访问，并避免使用配置数据来传递机密。
在云平台上运行 Kubernetes 时，限制对实例凭据的权限，使用
[网络策略](/zh/docs/tasks/administer-cluster/declare-network-policy/)
限制对 metadata API 的 pod 访问，并避免使用配置数据来传递机密。
<!--
### Controlling which nodes pods may access
@ -241,11 +276,17 @@ As an administrator, a beta admission plugin `PodNodeSelector` can be used to fo
within a namespace to default or require a specific node selector, and if end users cannot
alter namespaces, this can strongly limit the placement of all of the pods in a specific workload.
-->
### 控制 pod 可以访问那些节点
### 控制 Pod 可以访问哪些节点
默认情况下，对哪些节点可以运行 pod 没有任何限制。Kubernetes 给最终用户提供了[一组丰富的策略用于控制 pod 放在节点上的位置](/docs/concepts/configuration/assign-pod-node/)，以及[基于 pod 位置和驱逐的污点](/docs/concepts/configuration/taint-and-toleration/)。对于许多集群，可以约定由作者采用或者强制通过工具使用这些策略来分离工作负载。
默认情况下，对哪些节点可以运行 pod 没有任何限制。
Kubernetes 给最终用户提供了
[一组丰富的策略用于控制 pod 放在节点上的位置](/zh/docs/concepts/scheduling-eviction/assign-pod-node/)，
以及[基于污点的 Pod 放置和驱逐](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。
对于许多集群，可以约定由作者采用或者强制通过工具使用这些策略来分离工作负载。
作为管理员，β 特性的准入插件 `PodNodeSelector` 可用于强制命名空间中的 pod 使用默认或需要使用特定的节点选择器。如果最终用户无法改变命名空间，这可以强烈地限制所有的 pod 在特定工作负载的位置。
对于管理员，Beta 阶段的准入插件 `PodNodeSelector` 可用于强制命名空间中的 Pod
使用默认或需要使用特定的节点选择器。
如果最终用户无法改变命名空间，这可以强烈地限制所有的 pod 在特定工作负载的位置。
<!--
## Protecting cluster components from compromise
@ -274,10 +315,16 @@ access to a subset of the keyspace is strongly recommended.
-->
### 限制访问 etcd
对于 API 来说，拥有 etcd 后端的写访问权限，相当于获得了整个集群的 root 权限，并且可以使用写访问权限来相当快速地升级。从 API 服务器访问它们的 etcd 服务器，管理员应该使用广受信任的凭证，如通过 TLS 客户端证书的相互认证。往往，我们建议将 etcd 服务器隔离到只有API服务器可以访问的防火墙后面。
对于 API 来说，拥有 etcd 后端的写访问权限，相当于获得了整个集群的 root 权限，
并且可以使用写访问权限来相当快速地升级。
从 API 服务器访问它们的 etcd 服务器，管理员应该使用广受信任的凭证，
如通过 TLS 客户端证书的相互认证。
通常，我们建议将 etcd 服务器隔离到只有API服务器可以访问的防火墙后面。
{{< caution >}}
允许集群中其它组件拥有读或写全空间的权限去访问 etcd 实例，相当于授予群集管理员访问的权限。对于非 master 组件，强烈推荐使用单独的 etcd 实例，或者使用 etcd 的访问控制列表去限制只能读或者写空间的一个子集。
允许集群中其它组件拥有读或写全空间的权限去访问 etcd 实例，相当于授予群集管理员访问的权限。
对于非主控组件，强烈推荐使用单独的 etcd 实例，或者使用 etcd 的访问控制列表
去限制只能读或者写空间的一个子集。
{{< /caution >}}
<!--
@ -289,7 +336,9 @@ and archive the audit file on a secure server.
-->
### 开启审计日志
[审计日志](/docs/tasks/debug-application-cluster/audit/)是 β 特性，记录了 API 在发生破坏时进行后续分析的操作。建议启用审计日志，并将审计文件归档到安全服务器上。
[审计日志](/zh/docs/tasks/debug-application-cluster/audit/)是 Beta 特性，
负责记录 API 操作以便在发生破坏时进行事后分析。
建议启用审计日志，并将审计文件归档到安全服务器上。
<!--
### Restrict access to alpha or beta features
@ -299,9 +348,11 @@ that result in security vulnerabilities. Always assess the value an alpha or bet
provide against the possible risk to your security posture. When in doubt, disable features you
do not use.
-->
### 限制使用 α 和 β 特性
### 限制使用 alpha 和 beta 特性
Kubernetes 的 α 和 β 特性还在积极发展当中，可能存在导致安全漏洞的缺陷或错误。要始终评估 α 和 β 特性可能为您的安全态势带来的风险。当您怀疑存在风险时，可以禁用那些不需要使用的特性。
Kubernetes 的 alpha 和 beta 特性还在努力开发中，可能存在导致安全漏洞的缺陷或错误。
要始终评估 alpha 和 beta 特性可能为你的安全态势带来的风险。
当你怀疑存在风险时，可以禁用那些不需要使用的特性。
<!--
### Rotate infrastructure credentials frequently
@ -312,9 +363,13 @@ an authentication provider that can control how long issued tokens are available
lifetimes where possible. If you use service account tokens in external integrations, plan to
rotate those tokens frequently. For example, once the bootstrap phase is complete, a bootstrap token used for setting up nodes should be revoked or its authorization removed.
-->
### 频繁回收基础证书
### 频繁回收基础设施证书
一个 secret 或凭据的寿命越短，攻击者就越难使用该凭据，在证书上设置短生命周期并实现自动回收，是控制安全的一个好方法。因此，使用身份验证提供程序时，应该要求可以控制发布令牌的可用时间，并尽可能使用短寿命。如果在外部集成中使用服务帐户令牌，则应该频繁地回收这些令牌。例如，一旦引导阶段完成，就应该撤销用于设置节点的引导令牌，或者取消它的授权。
一个 Secret 或凭据的寿命越短，攻击者就越难使用该凭据。
在证书上设置短生命周期并实现自动回收，是控制安全的一个好方法。
因此，使用身份验证提供程序时，应该要求可以控制发布令牌的可用时间，并尽可能使用短寿命。
如果在外部集成中使用服务帐户令牌，则应该频繁地回收这些令牌。
例如，一旦引导阶段完成，就应该撤销用于设置节点的引导令牌，或者取消它的授权。
<!--
### Review third party integrations before enabling them
@ -332,9 +387,16 @@ or run with elevated permissions if those service accounts are granted access to
-->
### 在启用第三方集成之前，请先审查它们
许多集成到 Kubernetes 的第三方都可以改变您集群的安全配置。启用集成时，在授予访问权限之前，您应该始终检查扩展请求的权限。例如，许多安全集成可以请求访问来查看集群上的所有 secret，从而有效地使该组件成为集群管理。当有疑问时，如果可能的话，将集成限制在单个命名空间中运行。
许多集成到 Kubernetes 的第三方都可以改变你集群的安全配置。
启用集成时，在授予访问权限之前，你应该始终检查扩展所请求的权限。
例如，许多安全集成可以请求访问来查看集群上的所有 Secret，
从而有效地使该组件成为集群管理。
当有疑问时，如果可能的话，将集成限制在单个命名空间中运行。
如果组件创建的 pod 能够在命名空间中做一些类似 `kube-system` 命名空间中的事情，那么它也可能是出乎意料的强大。因为这些 pod 可以访问服务账户的 secret，或者，如果这些服务帐户被授予访问许可的 [pod 安全策略](/docs/concepts/policy/pod-security-policy/)的权限，它们能以高权限运行。
如果组件创建的 Pod 能够在命名空间中做一些类似 `kube-system` 命名空间中的事情，
那么它也可能是出乎意料的强大。
因为这些 Pod 可以访问服务账户的 Secret，或者，如果这些服务帐户被授予访问许可的
[Pod 安全策略](/zh/docs/concepts/policy/pod-security-policy/)的权限，它们能以高权限运行。
<!--
### Encrypt secrets at rest
@ -349,11 +411,16 @@ parties that gain access to your etcd backups from viewing the content of those
this feature is currently experimental, it may offer an additional level of defense when backups
are not encrypted or an attacker gains read access to etcd.
-->
### 使用加密的 rest
### 对 Secret 进行静态加密
一般情况下，etcd 数据库包含了通过 Kubernetes API 可以访问到的所有信息，并且可以授予攻击者对集群状态的可见性。始终使用经过良好审查的备份和加密解决方案来加密备份，并考虑在可能的情况下使用全磁盘加密。
一般情况下，etcd 数据库包含了通过 Kubernetes API 可以访问到的所有信息，
并且可以授予攻击者对集群状态的可见性。
始终使用经过良好审查的备份和加密解决方案来加密备份，并考虑在可能的情况下使用全磁盘加密。
Kubernetes 1.7 包含了 [rest 加密](/docs/tasks/administer-cluster/encrypt-data/)，它是一个 α 特性，会加密 etcd 里面的 `Secret` 资源，以防止某一方通过查看这些 secret 的内容获取 etcd 的备份。虽然目前这还只是实验性的功能，但是在备份没有加密或者攻击者获取到 etcd 的读访问权限的时候，它能提供额外的防御层级。
Kubernetes 1.7 包含了[静态数据加密](/zh/docs/tasks/administer-cluster/encrypt-data/)，
它是一个 alpha 特性，会加密 etcd 里面的 `Secret` 资源，以防止某一方通过查看
etcd 的备份文件查看到这些 Secret 的内容。虽然目前这还只是实验性的功能，
但是在备份没有加密或者攻击者获取到 etcd 的读访问权限的时候，它能提供额外的防御层级。
<!--
### Receiving alerts for security updates and reporting vulnerabilities
@ -364,7 +431,9 @@ page for more on how to report vulnerabilities.
-->
### 接收安全更新和报告漏洞的警报
加入 [kubernetes-announce](https://groups.google.com/forum/#!forum/kubernetes-announce) 组，能够获取有关安全公告的邮件。有关如何报告漏洞的更多信息，请参见 [安全报告](/security/)页面。
加入 [kubernetes-announce](https://groups.google.com/forum/#!forum/kubernetes-announce)
组，能够获取有关安全公告的邮件。有关如何报告漏洞的更多信息，请参见
[安全报告](/zh/docs/reference/issues-security/security/)页面。

220
content/zh/docs/tasks/administer-cluster/sysctl-cluster.md
View File

@ -1,52 +1,46 @@
---
title: 在 Kubernetes 集群中使用 sysctl
reviewers:
- sttts
content_type: task
---
<!--
---
title: Using sysctls in a Kubernetes Cluster
reviewers:
- sttts
content_type: task
---
--->
<!-- overview -->
{{< feature-state for_k8s_version="v1.11" state="beta" >}}
{{< feature-state for_k8s_version="v1.12" state="beta" >}}
<!--
This document describes how to configure and use kernel parameters within a
Kubernetes cluster using the sysctl interface.
--->
本文档介绍如何通过 sysctl 接口在 Kubernetes 集群中配置和使用内核参数。
Kubernetes cluster using the {{< glossary_tooltip term_id="sysctl" >}}
interface.
-->
本文档介绍如何通过 {{< glossary_tooltip term_id="sysctl" >}}
接口在 Kubernetes 集群中配置和使用内核参数。
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- steps -->
<!--
## Listing all Sysctl Parameters
--->
-->
## 获取 Sysctl 的参数列表
<!--
In Linux, the sysctl interface allows an administrator to modify kernel
parameters at runtime. Parameters are available via the `/proc/sys/` virtual
process file system. The parameters cover various subsystems such as:
--->
在 Linux 中，管理员可以通过 sysctl 接口修改内核运行时的参数。在 `/proc/sys/` 虚拟文件系统下存放许多内核参数。这些参数涉及了多个内核子系统，如：
-->
在 Linux 中，管理员可以通过 sysctl 接口修改内核运行时的参数。在 `/proc/sys/`
虚拟文件系统下存放许多内核参数。这些参数涉及了多个内核子系统，如：
<!--
- kernel (common prefix: `kernel.`)
@ -54,12 +48,12 @@ process file system. The parameters cover various subsystems such as:
- virtual memory (common prefix: `vm.`)
- MDADM (common prefix: `dev.`)
- More subsystems are described in [Kernel docs](https://www.kernel.org/doc/Documentation/sysctl/README).
--->
- 内核子系统 (通常前缀为: `kernel.`)
- 网络子系统 (通常前缀为: `net.`)
- 虚拟内存子系统 (通常前缀为: `vm.`)
- MDADM 子系统 (通常前缀为: `dev.`)
- 更多子系统请参见 [内核文档](https://www.kernel.org/doc/Documentation/sysctl/README)。
-->
- 内核子系统（通常前缀为: `kernel.`）
- 网络子系统（通常前缀为: `net.`）
- 虚拟内存子系统（通常前缀为: `vm.`）
- MDADM 子系统（通常前缀为: `dev.`）
- 更多子系统请参见[内核文档](https://www.kernel.org/doc/Documentation/sysctl/README)。
<!--
To get a list of all parameters, you can run
@ -67,27 +61,28 @@ To get a list of all parameters, you can run
若要获取完整的参数列表，请执行以下命令
```shell
$ sudo sysctl -a
sudo sysctl -a
```
<!--
## Enabling Unsafe Sysctls
--->
## 启用非安全的 Sysctl 参数
<!--
Sysctls are grouped into _safe_ and _unsafe_ sysctls. In addition to proper
namespacing a _safe_ sysctl must be properly _isolated_ between pods on the same
node. This means that setting a _safe_ sysctl for one pod
--->
sysctl 参数分为 _安全_ 和 _非安全的_。_安全_ sysctl 参数除了需要设置恰当的命名空间外，在同一 node 上的不同 Pod 之间也必须是 _相互隔离的_。这意味着在 Pod 上设置 _安全_ sysctl 参数
-->
## 启用非安全的 Sysctl 参数
sysctl 参数分为 _安全_ 和 _非安全的_。
_安全_ sysctl 参数除了需要设置恰当的命名空间外，在同一 node 上的不同 Pod
之间也必须是 _相互隔离的_。这意味着在 Pod 上设置 _安全_ sysctl 参数
<!--
- must not have any influence on any other pod on the node
- must not allow to harm the node's health
- must not allow to gain CPU or memory resources outside of the resource limits
of a pod.
--->
-->
- 必须不能影响到节点上的其他 Pod
- 必须不能损害节点的健康
- 必须不允许使用超出 Pod 的资源限制的 CPU 或内存资源。
@ -95,117 +90,130 @@ sysctl 参数分为 _安全_ 和 _非安全的_。_安全_ sysctl 参数除了
<!--
By far, most of the _namespaced_ sysctls are not necessarily considered _safe_.
The following sysctls are supported in the _safe_ set:
--->
至今为止，大多数 _有命名空间的_ sysctl 参数不一定被认为是 _安全_ 的。以下几种 sysctl 参数是 _安全的_：
-->
至今为止，大多数 _有命名空间的_ sysctl 参数不一定被认为是 _安全_ 的。
以下几种 sysctl 参数是 _安全的_：
- `kernel.shm_rmid_forced`,
- `net.ipv4.ip_local_port_range`,
- `net.ipv4.tcp_syncookies`.
- `kernel.shm_rmid_forced`
- `net.ipv4.ip_local_port_range`
- `net.ipv4.tcp_syncookies`
- `net.ipv4.ping_group_range` （从 Kubernetes 1.18 开始）
{{< note >}}
<!--
The example `net.ipv4.tcp_syncookies` is not namespaced on Linux kernel version 4.4 or lower.
--->
**注意**: 示例中的 `net.ipv4.tcp_syncookies` 在Linux 内核 4.4 或更低的版本中是无命名空间的。
-->
{{< note >}}
示例中的 `net.ipv4.tcp_syncookies` 在Linux 内核 4.4 或更低的版本中是无命名空间的。
{{< /note >}}
<!--
This list will be extended in future Kubernetes versions when the kubelet
supports better isolation mechanisms.
--->
在未来的 Kubernetes 版本中，若kubelet 支持更好的隔离机制，则上述列表中将会列出更多 _安全的_ sysctl 参数。
-->
在未来的 Kubernetes 版本中，若 kubelet 支持更好的隔离机制，则上述列表中将会
列出更多 _安全的_ sysctl 参数。
<!--
All _safe_ sysctls are enabled by default.
--->
-->
所有 _安全的_ sysctl 参数都默认启用。
<!--
All _unsafe_ sysctls are disabled by default and must be allowed manually by the
cluster admin on a per-node basis. Pods with disabled unsafe sysctls will be
scheduled, but will fail to launch.
--->
所有 _非安全的_ sysctl 参数都默认禁用，且必须由集群管理员在每个节点上手动开启。那些设置了不安全 sysctl 参数的 Pod 仍会被调度，但无法正常启动。
-->
所有 _非安全的_ sysctl 参数都默认禁用，且必须由集群管理员在每个节点上手动开启。
那些设置了不安全 sysctl 参数的 Pod 仍会被调度，但无法正常启动。
<!--
With the warning above in mind, the cluster admin can allow certain _unsafe_
sysctls for very special situations like e.g. high-performance or real-time
application tuning. _Unsafe_ sysctls are enabled on a node-by-node basis with a
flag of the kubelet, e.g.:
--->
参考上述警告，集群管理员只有在一些非常特殊的情况下（如：高可用或实时应用调整），才可以启用特定的 _非安全的_ sysctl 参数。如需启用 _非安全的_ sysctl 参数，请您在每个节点上分别设置 kubelet 命令行参数，例如：
-->
参考上述警告，集群管理员只有在一些非常特殊的情况下（如：高可用或实时应用调整），
才可以启用特定的 _非安全的_ sysctl 参数。
如需启用 _非安全的_ sysctl 参数，请你在每个节点上分别设置 kubelet 命令行参数，例如：
```shell
$ kubelet --allowed-unsafe-sysctls \
kubelet --allowed-unsafe-sysctls \
'kernel.msg*,net.core.somaxconn' ...
```
<!--
For minikube, this can be done via the `extra-config` flag:
--->
如果您使用 minikube，可以通过 `extra-config` 参数来配置：
For {{< glossary_tooltip term_id="minikube" >}}, this can be done via the `extra-config` flag:
-->
如果你使用 {{< glossary_tooltip term_id="minikube" >}}，可以通过 `extra-config` 参数来配置：
```shell
$ minikube start --extra-config="kubelet.AllowedUnsafeSysctls=kernel.msg*,net.core.somaxconn"...
minikube start --extra-config="kubelet.AllowedUnsafeSysctls=kernel.msg*,net.core.somaxconn"...
```
<!--
Only _namespaced_ sysctls can be enabled this way.
--->
-->
只有 _有命名空间的_ sysctl 参数可以通过该方式启用。
<!--
## Setting Sysctls for a Pod
--->
## 设置 Pod 的 Sysctl 参数
<!--
A number of sysctls are _namespaced_ in today's Linux kernels. This means that
they can be set independently for each pod on a node. Only namespaced sysctls
are configurable via the pod securityContext within Kubernetes.
--->
目前，在 Linux 内核中，有许多的 sysctl 参数都是 _有命名空间的_ 。 这就意味着可以为节点上的每个 Pod 分别去设置它们的 sysctl 参数。 在 Kubernetes 中，只有那些有命名空间的 sysctl 参数可以通过 Pod 的 securityContext 对其进行配置。
-->
## 设置 Pod 的 Sysctl 参数
目前，在 Linux 内核中，有许多的 sysctl 参数都是 _有命名空间的_ 。
这就意味着可以为节点上的每个 Pod 分别去设置它们的 sysctl 参数。
在 Kubernetes 中，只有那些有命名空间的 sysctl 参数可以通过 Pod 的 securityContext 对其进行配置。
<!--
The following sysctls are known to be namespaced. This list could change
in future versions of the Linux kernel.
--->
-->
以下列出有命名空间的 sysctl 参数，在未来的 Linux 内核版本中，此列表可能会发生变化。
- `kernel.shm*`,
- `kernel.msg*`,
- `kernel.sem`,
- `fs.mqueue.*`,
- `net.*`（内核中网络配置项相关参数），如果它可以在容器命名空间里被更改。然而，也有一些特例
(例如，`net.netfilter.nf_conntrack_max` 和
`net.netfilter.nf_conntrack_expect_max`
可以在容器命名空间里被更改，但它们是非命名空间的)。
- `net.*`（内核中可以在容器命名空间里被更改的网络配置项相关参数）。然而也有一些特例
（例如，`net.netfilter.nf_conntrack_max` 和 `net.netfilter.nf_conntrack_expect_max`
可以在容器命名空间里被更改，但它们是非命名空间的）。
<!--
Sysctls with no namespace are called _node-level_ sysctls. If you need to set
them, you must manually configure them on each node's operating system, or by
using a DaemonSet with privileged containers.
--->
没有命名空间的 sysctl 参数称为 _节点级别的_ sysctl 参数。 如果需要对其进行设置，则必须在每个节点的操作系统上手动地去配置它们，或者通过在 DaemonSet 中运行特权模式容器来配置。
-->
没有命名空间的 sysctl 参数称为 _节点级别的_ sysctl 参数。
如果需要对其进行设置，则必须在每个节点的操作系统上手动地去配置它们，
或者通过在 DaemonSet 中运行特权模式容器来配置。
<!--
Use the pod securityContext to configure namespaced sysctls. The securityContext
applies to all containers in the same pod.
--->
可使用 pod 的 securityContext 来配置有命名空间的 sysctl 参数，securityContext 应用于同一个 pod 中的所有容器。
-->
可使用 Pod 的 securityContext 来配置有命名空间的 sysctl 参数，
securityContext 应用于同一个 Pod 中的所有容器。
<!--
This example uses the pod securityContext to set a safe sysctl
`kernel.shm_rmid_forced` and two unsafe sysctls `net.core.somaxconn` and
`kernel.msgmax` There is no distinction between _safe_ and _unsafe_ sysctls in
the specification.
--->
此示例中，使用 Pod SecurityContext 来对一个安全的 sysctl 参数 `kernel.shm_rmid_forced` 以及两个非安全的 sysctl 参数 `net.core.somaxconn`和 `kernel.msgmax` 进行设置。在 Pod 规格中对 _安全的_ 和 _非安全的_ sysctl 参数不做区分。
-->
此示例中，使用 Pod SecurityContext 来对一个安全的 sysctl 参数
`kernel.shm_rmid_forced` 以及两个非安全的 sysctl 参数
`net.core.somaxconn` 和 `kernel.msgmax` 进行设置。
在 Pod 规约中对 _安全的_ 和 _非安全的_ sysctl 参数不做区分。
{{< warning >}}
<!--
Only modify sysctl parameters after you understand their effects, to avoid
destabilizing your operating system.
--->
为了避免破坏操作系统的稳定性，请您在了解变更后果之后再修改 sysctl 参数。
-->
{{< warning >}}
为了避免破坏操作系统的稳定性，请你在了解变更后果之后再修改 sysctl 参数。
{{< /warning >}}
```yaml
@ -227,14 +235,15 @@ spec:
<!-- discussion -->
{{< warning >}}
<!--
Due to their nature of being _unsafe_, the use of _unsafe_ sysctls
is at-your-own-risk and can lead to severe problems like wrong behavior of
containers, resource shortage or complete breakage of a node.
--->
**警告**：由于 _非安全的_ sysctl 参数其本身具有不稳定性，在使用 _非安全的_ sysctl 参数时可能会导致一些严重问题，如容器的错误行为、机器资源不足或节点被完全破坏，用户需自行承担风险。
-->
{{< warning >}}
由于 _非安全的_ sysctl 参数其本身具有不稳定性，在使用 _非安全的_ sysctl 参数
时可能会导致一些严重问题，如容器的错误行为、机器资源不足或节点被完全破坏，
用户需自行承担风险。
{{< /warning >}}
<!--
@ -242,8 +251,11 @@ It is good practice to consider nodes with special sysctl settings as
_tainted_ within a cluster, and only schedule pods onto them which need those
sysctl settings. It is suggested to use the Kubernetes [_taints and toleration_
feature](/docs/reference/generated/kubectl/kubectl-commands/#taint) to implement this.
--->
最佳实践方案是将集群中具有特殊 sysctl 设置的节点视为 _受感染的_，并且只调度需要使用到特殊 sysctl 设置的 Pod 到这些节点上。 建议使用 Kubernetes 的 [ _taints 和 toleration_ 特性](/docs/reference/generated/kubectl/kubectl-commands/#taint) 来实现它。
-->
最佳实践方案是将集群中具有特殊 sysctl 设置的节点视为 _有污点的_，并且只调度
需要使用到特殊 sysctl 设置的 Pod 到这些节点上。
建议使用 Kubernetes 的
[污点和容忍度特性](/docs/reference/generated/kubectl/kubectl-commands/#taint) 来实现它。
<!--
A pod with the _unsafe_ sysctls will fail to launch on any node which has not
@ -252,10 +264,11 @@ is recommended to use
[_taints and toleration_ feature](/docs/reference/generated/kubectl/kubectl-commands/#taint) or
[taints on nodes](/docs/concepts/configuration/taint-and-toleration/)
to schedule those pods onto the right nodes.
--->
设置了 _非安全的_ sysctl 参数的 pod，在禁用了以下两种 _非安全的_ sysctl 参数配置的节点上启动都会失败。与 _节点级别的_ sysctl 一样，建议开启
[_taints 和 toleration_ 特性](/docs/reference/generated/kubectl/kubectl-commands/#taint) 或
[taints on nodes](/docs/concepts/configuration/taint-and-toleration/)
-->
设置了 _非安全的_ sysctl 参数的 Pod 在禁用了这两种 _非安全的_ sysctl 参数配置
的节点上启动都会失败。与 _节点级别的_ sysctl 一样，建议开启
[污点和容忍度特性](/docs/reference/generated/kubectl/kubectl-commands/#taint) 或
[为节点配置污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)
以便将 Pod 调度到正确的节点之上。
## PodSecurityPolicy
@ -266,56 +279,72 @@ sysctls or sysctl patterns in the `forbiddenSysctls` and/or
`allowedUnsafeSysctls` fields of the PodSecurityPolicy. A sysctl pattern ends
with a `*` character, such as `kernel.*`. A `*` character on its own matches
all sysctls.
--->
您可以通过在 PodSecurityPolicy 的 `forbiddenSysctls` 和/或 `allowedUnsafeSysctls` 字段中，指定 sysctl 或填写 sysctl 匹配模式来进一步为 Pod 设置 sysctl 参数。sysctl 参数匹配模式以 `*` 字符结尾，如 `kernel.*`。 单独的 `*` 字符匹配所有 sysctl 参数。
-->
你可以通过在 PodSecurityPolicy 的 `forbiddenSysctls` 和/或 `allowedUnsafeSysctls`
字段中，指定 sysctl 或填写 sysctl 匹配模式来进一步为 Pod 设置 sysctl 参数。
sysctl 参数匹配模式以 `*` 字符结尾，如 `kernel.*`。
单独的 `*` 字符匹配所有 sysctl 参数。
<!--
By default, all safe sysctls are allowed.
--->
-->
所有 _安全的_ sysctl 参数都默认启用。
<!--
Both `forbiddenSysctls` and `allowedUnsafeSysctls` are lists of plain sysctl names
or sysctl patterns (which end with `*`). The string `*` matches all sysctls.
--->
`forbiddenSysctls` 和 `allowedUnsafeSysctls` 的值都是字符串列表类型，可以添加 sysctl 参数名称，也可以添加 sysctl 参数匹配模式（以`*`结尾）。 只填写 `*` 则匹配所有的 sysctl 参数。
-->
`forbiddenSysctls` 和 `allowedUnsafeSysctls` 的值都是字符串列表类型，
可以添加 sysctl 参数名称，也可以添加 sysctl 参数匹配模式（以`*`结尾）。
只填写 `*` 则匹配所有的 sysctl 参数。
<!--
The `forbiddenSysctls` field excludes specific sysctls. You can forbid a
combination of safe and unsafe sysctls in the list. To forbid setting any
sysctls, use `*` on its own.
--->
`forbiddenSysctls` 字段用于禁用特定的 sysctl 参数。 您可以在列表中禁用安全和非安全的 sysctl 参数的组合。 要禁用所有的 sysctl 参数，请设置为 `*`。
-->
`forbiddenSysctls` 字段用于禁用特定的 sysctl 参数。
你可以在列表中禁用安全和非安全的 sysctl 参数的组合。
要禁用所有的 sysctl 参数，请设置为 `*`。
<!--
If you specify any unsafe sysctl in the `allowedUnsafeSysctls` field and it is
not present in the `forbiddenSysctls` field, that sysctl can be used in Pods
using this PodSecurityPolicy. To allow all unsafe sysctls in the
PodSecurityPolicy to be set, use `*` on its own.
--->
如果要在 `allowedUnsafeSysctls` 字段中指定一个非安全的 sysctl 参数，并且它在`forbiddenSysctls` 字段中未被禁用，则可以在 Pod 中通过 PodSecurityPolicy 启用该 sysctl 参数。 若要在 PodSecurityPolicy 中开启所有非安全的 sysctl 参数，请设 `allowedUnsafeSysctls` 字段值为 `*`。
-->
如果要在 `allowedUnsafeSysctls` 字段中指定一个非安全的 sysctl 参数，
并且它在 `forbiddenSysctls` 字段中未被禁用，则可以在 Pod 中通过
PodSecurityPolicy 启用该 sysctl 参数。
若要在 PodSecurityPolicy 中开启所有非安全的 sysctl 参数，
请设 `allowedUnsafeSysctls` 字段值为 `*`。
<!--
Do not configure these two fields such that there is overlap, meaning that a
given sysctl is both allowed and forbidden.
--->
`allowedUnsafeSysctls` 与 `forbiddenSysctls` 两字段的配置不能重叠，否则这就意味着存在某个 sysctl 参数既被启用又被禁用。
-->
`allowedUnsafeSysctls` 与 `forbiddenSysctls` 两字段的配置不能重叠，
否则这就意味着存在某个 sysctl 参数既被启用又被禁用。
{{< warning >}}
<!--
If you whitelist unsafe sysctls via the `allowedUnsafeSysctls` field
in a PodSecurityPolicy, any pod using such a sysctl will fail to start
if the sysctl is not whitelisted via the `--allowed-unsafe-sysctls` kubelet
flag as well on that node.
--->
**警告**：如果您通过 PodSecurityPolicy 中的 `allowedUnsafeSysctls` 字段将非安全的 sysctl 参数列入白名单，但该 sysctl 参数未通过 kubelet 命令行参数 `--allowed-unsafe-sysctls` 在节点上将其列入白名单，则设置了这个 sysctl 参数的 Pod 将会启动失败。
{{< warning >}}
如果你通过 PodSecurityPolicy 中的 `allowedUnsafeSysctls` 字段将非安全的 sysctl
参数列入白名单，但该 sysctl 参数未通过 kubelet 命令行参数
`--allowed-unsafe-sysctls` 在节点上将其列入白名单，则设置了这个 sysctl
参数的 Pod 将会启动失败。
{{< /warning >}}
<!--
This example allows unsafe sysctls prefixed with `kernel.msg` to be set and
disallows setting of the `kernel.shm_rmid_forced` sysctl.
--->
以下示例设置启用了以 `kernel.msg` 为前缀的非安全的 sysctl 参数，以及禁用了 sysctl 参数 `kernel.shm_rmid_forced`。
-->
以下示例设置启用了以 `kernel.msg` 为前缀的非安全的 sysctl 参数，同时禁用了
sysctl 参数 `kernel.shm_rmid_forced`。
```yaml
apiVersion: policy/v1beta1
@ -330,4 +359,3 @@ spec:
...
```