diff --git a/content/zh-cn/docs/concepts/policy/resource-quotas.md b/content/zh-cn/docs/concepts/policy/resource-quotas.md index 3bd39820bd..1ef998fff8 100644 --- a/content/zh-cn/docs/concepts/policy/resource-quotas.md +++ b/content/zh-cn/docs/concepts/policy/resource-quotas.md @@ -23,58 +23,115 @@ weight: 20 When several users or teams share a cluster with a fixed number of nodes, there is a concern that one team could use more than its fair share of resources. -Resource quotas are a tool for administrators to address this concern. +_Resource quotas_ are a tool for administrators to address this concern. --> 当多个用户或团队共享具有固定节点数目的集群时,人们会担心有人使用超过其基于公平原则所分配到的资源量。 -资源配额是帮助管理员解决这一问题的工具。 +**资源配额**是帮助管理员解决这一问题的工具。 + + +资源配额,由 ResourceQuota 对象定义, +提供了限制每个{{< glossary_tooltip text="命名空间" term_id="namespace" >}}的资源总消耗的约束。 +资源配额还可以限制在命名空间中可以创建的[对象数量](#quota-on-object-count)(按 API 类型计算), +以及该命名空间中存在的 API +对象可能消耗的{{< glossary_tooltip text="基础设施资源" term_id="infrastructure-resource" >}}的总量。 + +{{< caution >}} + +不同的资源争用,或者资源配额的更改不会影响已经创建的资源。 +{{< /caution >}} -资源配额,通过 `ResourceQuota` 对象来定义,对每个命名空间的资源消耗总量提供限制。 -它可以限制命名空间中某种类型的对象的总数目上限,也可以限制命名空间中的 Pod 可以使用的计算资源的总上限。 +## Kubernetes ResourceQuota 的工作原理 {#how-kubernetes-resourcequotas-work} -资源配额的工作方式如下: +ResourceQuota 的工作方式如下: + + +- 不同团队在不同的命名空间中工作。 + 这种分离可以通过 [RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/) + 或任何其他[鉴权](/zh-cn/docs/reference/access-authn-authz/authorization/)机制来强制执行。 + +- 集群管理员为每个命名空间创建至少一个 ResourceQuota。 + - 为了确保强制执行不被解除,集群管理员还应限制对删除或更新此 ResourceQuota 的访问; + 例如,通过定义一个[验证准入策略](/zh-cn/docs/reference/access-authn-authz/validating-admission-policy/)来实现这点。 -- 不同的团队可以在不同的命名空间下工作,这可以通过 - [RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/) 强制执行。 -- 集群管理员可以为每个命名空间创建一个或多个 ResourceQuota 对象。 - 当用户在命名空间下创建资源(如 Pod、Service 等)时,Kubernetes 的配额系统会跟踪集群的资源使用情况, 以确保使用的资源用量不超过 ResourceQuota 中定义的硬性资源限额。 -- 如果资源创建或者更新请求违反了配额约束,那么该请求会报错(HTTP 403 FORBIDDEN), - 并在消息中给出有可能违反的约束。 -- 如果命名空间下的计算资源(如 `cpu` 和 `memory`)的配额被启用, - 则用户必须为这些资源设定请求值(request)和约束值(limit),否则配额系统将拒绝 Pod 的创建。 - 提示: 可使用 `LimitRanger` 准入控制器来为没有设置计算资源需求的 Pod 设置默认值。 - - 若想避免这类问题,请参考 - [演练](/zh-cn/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)示例。 + + 你可以对 ResourceQuota 应用一个[范围](#quota-scopes),以限制其适用的地方。 + +- 如果创建或更新资源违反了配额约束,控制平面将使用 HTTP 状态码 + `403 Forbidden` 拒绝该请求。错误信息包括解释将要违反的约束的说明。 + + +- 如果在命名空间中为诸如 `cpu` 和 `memory` + 的{{< glossary_tooltip text="资源" term_id="infrastructure-resource" >}}启用了配额, + 用户在定义 Pod 时必须指定这些值的请求或限制;否则,配额系统可能会拒绝 Pod 创建。 + + 资源配额[演练](/zh-cn/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)展示了一个如何避免此问题的示例。 {{< note >}} + +你通常不会直接创建 Pod;例如,你更常创建一个[工作负载管理](/zh-cn/docs/concepts/workloads/controllers/)对象, +如 {{< glossary_tooltip term_id="deployment" >}}。 +如果你创建了一个尝试使用超出可用资源的 Deployment(或其他工作负载管理对象), +其创建**会成功**,但 Deployment 可能无法使其管理的所有 Pod 都运行起来。 +在这种情况下,你可以使用 `kubectl describe` 等命令检查 Deployment 的状态, +以查看发生了什么。 + 在集群容量小于各命名空间配额总和的情况下,可能存在资源竞争。资源竞争时,Kubernetes 系统会遵循先到先得的原则。 -不管是资源竞争还是配额的修改,都不会影响已经创建的资源使用对象。 - -- 参阅[资源配额设计文档](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_resource_quota.md)。 - 参阅[如何使用资源配额的详细示例](/zh-cn/docs/tasks/administer-cluster/quota-api-object/)。 -- 参阅[优先级类配额支持的设计文档](https://git.k8s.io/design-proposals-archive/scheduling/pod-priority-resourcequota.md)了解更多信息。 -- 参阅 [LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765)。 +- 阅读 ResourceQuota [API 参考](/zh-cn/docs/reference/kubernetes-api/policy-resources/resource-quota-v1/) +- 了解 [LimitRanges](/zh-cn/docs/concepts/policy/limit-range/) +- 你可以阅读历史的 + [ResourceQuota 设计文档](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_resource_quota.md)获取更多信息。 +- 你也可以阅读[优先级类配额支持设计文档](https://git.k8s.io/design-proposals-archive/scheduling/pod-priority-resourcequota.md)。