Translate doc resource-quotas into chinese #5636
Conversation
k8s-ci-robot
added
the
size/L
k8s-ci-robot
added
the
cncf-cla: yes
|
Deploy preview ready! Built with commit c88e80b https://deploy-preview-5636--kubernetes-io-master-staging.netlify.com |
| title: 资源配额 | ||
| --- | ||
|
|
||
| 当多个用户或团队共享具有固定数目节点的群集时，人们会担心有人使用的资源超出应有的份额。 |
|
|
||
| 资源配额是管理员解决这一问题的工具。 | ||
|
|
||
| 资源配额， 通过 `ResourceQuota` 对象来定义， 对每个命名空间的资源消耗总量提供限制。 它可以限制命名空间下按类型创建的对象的数量，也可以限制可被该项目以资源形式消耗的计算资源的总量。 |
There was a problem hiding this comment.
它可以限制命名空间下按类型创建的对象的数量
->
它可以按类型限制名字空间下可以创建的对象的数量
|
|
||
| 资源配额， 通过 `ResourceQuota` 对象来定义， 对每个命名空间的资源消耗总量提供限制。 它可以限制命名空间下按类型创建的对象的数量，也可以限制可被该项目以资源形式消耗的计算资源的总量。 | ||
|
|
||
| 资源配额以如下方式生效： |
|
|
||
| 资源配额以如下方式生效： | ||
|
|
||
| - 不同的团队运作在不同的命名空间下。 目前这是自愿的， 但计划通过ACL (Access Control List 访问控制列表) |
There was a problem hiding this comment.
不同的团队运作在不同的命名空间下。
->
不同的团队在不同的命名空间下工作。
|
|
||
| - 不同的团队运作在不同的命名空间下。 目前这是自愿的， 但计划通过ACL (Access Control List 访问控制列表) | ||
| 使其变为强制性的。 | ||
| - 管理员为每个命名空间创建一个或多个资源配额。 |
|
|
||
| 用户可以对给定命名空间下的 [存储资源](/docs/user-guide/persistent-volumes) 总量进行限制。 | ||
|
|
||
| 此外，还可以根据相关的storage-class来限制存储资源的消耗。 |
There was a problem hiding this comment.
storage-class -> 存储类（Storage Class）
| | ------------------------------- | ------------------------------------------------- | | ||
| | `configmaps` | 命名空间下允许存在的configmap的数量。 | | ||
| | `persistentvolumeclaims` | 命名空间下允许存在的[PVC](/docs/user-guide/persistent-volumes/#persistentvolumeclaims)的数量。 | | ||
| | `pods` | 命名空间下允许存在的非终止状态的pod数量。 如果pod `status.phase 为 (Failed, Succeeded)` ， 那么其处于终止状态。 | |
There was a problem hiding this comment.
pod status.phase 为 (Failed, Succeeded)
->
pod的status.phase为 Failed 或者 Succeeded
|
|
||
| 用户可能希望在命名空间中为pod设置配额，来避免有用户创建很多小的pod，从而耗尽集群提供的pod IP地址。 | ||
|
|
||
| ## 配额范围 |
| * `requests.cpu` | ||
| * `requests.memory` | ||
|
|
||
| ## 需求和限额 |
| - 允许每个租户根据需要增加资源使用量，但要有足够的限制以防止意外资源耗尽。 | ||
| - 在命名空间中添加节点、提高配额的额外需求。 | ||
|
|
||
| 这些策略可以使用 ResourceQuota 作为构建模块，通过编写一个检测配额使用，并根据其他信号调整各命名空间下的配额硬性限制的 "控制器" 来实现。 |
|
@tengqm 感谢检视，已更新 |
|
@lichuqiang 之所以建议”名字空间“是觉得”命名空间“对应的英文应该是 ”naming space"。 |
|
@tengqm 已更新，为了避免歧义，还是保留了namespace英文原文 |
|
@tengqm @lichuqiang |
|
|
||
| 下面是使用namespace和配额构建策略的示例： | ||
|
|
||
| - 在具有 32 GiB 内存 和 16 处理器核容量的集群中， 允许A团队使用 20 GiB 内存 和 10 处理器核， |
There was a problem hiding this comment.
核是量词，10核处理器或者10核的CPU资源。比较好。
| 下面是使用namespace和配额构建策略的示例： | ||
|
|
||
| - 在具有 32 GiB 内存 和 16 处理器核容量的集群中， 允许A团队使用 20 GiB 内存 和 10 处理器核， | ||
| 允许B团队使用 10GiB 内存和 4 处理器核， 并且预留 2GiB 内存和 2 处理器核供将来分配。 |
|
|
||
| - 在具有 32 GiB 内存 和 16 处理器核容量的集群中， 允许A团队使用 20 GiB 内存 和 10 处理器核， | ||
| 允许B团队使用 10GiB 内存和 4 处理器核， 并且预留 2GiB 内存和 2 处理器核供将来分配。 | ||
| - 限制 "testing" namespace使用 1 处理器核和 1GiB 内存。 允许 "production" namespace使用任意数量。 |
|
|
||
| 当多个用户或团队共享具有固定数目节点的集群时，人们会担心有人使用的资源超出应有的份额。 | ||
|
|
||
| 资源配额是管理员解决这一问题的工具。 |
There was a problem hiding this comment.
资源配额是管理员解决这一问题的工具。
->
资源配额是帮助管理员解决这一问题的工具。
|
|
||
| ## 更多信息 | ||
|
|
||
| 查看 [资源配额设计文档](https://git.k8s.io/community/contributors/design-proposals/admission_control_resource_quota.md) 了解更多信息。 |
There was a problem hiding this comment.
|
@tengqm |
CN doc translation
/cc @tengqm @zhangxiaoyu-zidif
This change is