From 7d9eee664944bb38ca11c5b80a74c2e446d36736 Mon Sep 17 00:00:00 2001 From: "xin.li" Date: Wed, 15 May 2024 00:39:12 +0800 Subject: [PATCH] [zh-cn]sync api-extension/_index.md resource-quotas.md Signed-off-by: xin.li --- .../extend-kubernetes/api-extension/_index.md | 31 +++++++++ .../docs/concepts/policy/resource-quotas.md | 69 +++++++++++-------- 2 files changed, 72 insertions(+), 28 deletions(-) diff --git a/content/zh-cn/docs/concepts/extend-kubernetes/api-extension/_index.md b/content/zh-cn/docs/concepts/extend-kubernetes/api-extension/_index.md index ccdad410f0..9b9a3eb8bc 100644 --- a/content/zh-cn/docs/concepts/extend-kubernetes/api-extension/_index.md +++ b/content/zh-cn/docs/concepts/extend-kubernetes/api-extension/_index.md @@ -2,3 +2,34 @@ title: 扩展 Kubernetes API weight: 30 --- + + +自定义资源是 Kubernetes API 的扩展。 +Kubernetes 提供了两种将自定义资源添加到集群的方法： + + +- [CustomResourceDefinition](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/)（CRD） + 机制允许你通过指定自己的 API 组、种类和模式以声明方式定义新的自定义 API。 + Kubernetes 控制平面为自定义资源提供服务并为其提供存储。 + CRD 允许你为集群创建新的资源类别，而无需编写和运行自定义 API 服务器。 + +- [聚合层（Aggregation Layer）](/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)位于主 + API 服务器后面，将 API 服务器用作代理。 + 这种安排称为 API 聚合（API Aggregation，AA），允许你通过编写和部署自己的 API 服务器来为自定义资源提供专门的实现。 + 主 API 服务器将你指定的自定义 API 的请求委托给你的 API 服务器，使其可供所有客户端使用。 diff --git a/content/zh-cn/docs/concepts/policy/resource-quotas.md b/content/zh-cn/docs/concepts/policy/resource-quotas.md index 561f72c596..f3d13793b2 100644 --- a/content/zh-cn/docs/concepts/policy/resource-quotas.md +++ b/content/zh-cn/docs/concepts/policy/resource-quotas.md @@ -60,14 +60,14 @@ Resource quotas work like this: See the [walkthrough](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/) for an example of how to avoid this problem. --> -- 不同的团队可以在不同的命名空间下工作。这可以通过 +- 不同的团队可以在不同的命名空间下工作，这可以通过 [RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/) 强制执行。 - 集群管理员可以为每个命名空间创建一个或多个 ResourceQuota 对象。 - 当用户在命名空间下创建资源（如 Pod、Service 等）时，Kubernetes 的配额系统会跟踪集群的资源使用情况， 以确保使用的资源用量不超过 ResourceQuota 中定义的硬性资源限额。 - 如果资源创建或者更新请求违反了配额约束，那么该请求会报错（HTTP 403 FORBIDDEN）， 并在消息中给出有可能违反的约束。 -- 如果命名空间下的计算资源 （如 `cpu` 和 `memory`）的配额被启用， +- 如果命名空间下的计算资源（如 `cpu` 和 `memory`）的配额被启用， 则用户必须为这些资源设定请求值（request）和约束值（limit），否则配额系统将拒绝 Pod 的创建。 提示: 可使用 `LimitRanger` 准入控制器来为没有设置计算资源需求的 Pod 设置默认值。 @@ -195,8 +195,8 @@ In addition to the resources mentioned above, in release 1.10, quota support for --> ### 扩展资源的资源配额 {#resource-quota-for-extended-resources} -除上述资源外，在 Kubernetes 1.10 版本中，还添加了对 -[扩展资源](/zh-cn/docs/concepts/configuration/manage-resources-containers/#extended-resources) +除上述资源外，在 Kubernetes 1.10 版本中， +还添加了对[扩展资源](/zh-cn/docs/concepts/configuration/manage-resources-containers/#extended-resources) 的支持。 -如果所使用的是 CRI 容器运行时，容器日志会被计入临时存储配额。 -这可能会导致存储配额耗尽的 Pods 被意外地驱逐出节点。 -参考[日志架构](/zh-cn/docs/concepts/cluster-administration/logging/) -了解详细信息。 +如果所使用的是 CRI 容器运行时，容器日志会被计入临时存储配额， +这可能会导致存储配额耗尽的 Pod 被意外地驱逐出节点。 +参考[日志架构](/zh-cn/docs/concepts/cluster-administration/logging/)了解详细信息。 {{< /note >}} ## 对象数量配额 {#object-count-quota} -你可以使用以下语法对所有标准的、命名空间域的资源类型进行配额设置： +你可以使用以下语法为 Kubernetes API 中“一种特定资源类型的总数”设置配额： * `count/.`：用于非核心（core）组的资源 * `count/`：用于核心组的资源 @@ -309,7 +308,7 @@ namespaced resource types using the following syntax: -这是用户可能希望利用对象计数配额来管理的一组资源示例。 +这是用户可能希望利用对象计数配额来管理的一组资源示例： * `count/persistentvolumeclaims` * `count/services` @@ -323,21 +322,31 @@ Here is an example set of resources users may want to put under object count quo * `count/cronjobs.batch` -相同语法也可用于自定义资源。 +如果你以这种方式定义配额，它将应用于属于 API 服务器一部分的 Kubernetes API，以及 CustomResourceDefinition +支持的任何自定义资源。 +如果你使用[聚合 API](/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) +添加未定义为 CustomResourceDefinitions 的其他自定义 API，则核心 Kubernetes 控制平面不会对聚合 API 实施配额管理。 +如果合适，扩展 API 服务器需要为自定义 API 提供配额管理。 例如，要对 `example.com` API 组中的自定义资源 `widgets` 设置配额，请使用 `count/widgets.example.com`。 -当使用 `count/*` 资源配额时，如果对象存在于服务器存储中，则会根据配额管理资源。 +当使用这样的资源配额（几乎涵盖所有对象类别）时，如果对象类别在控制平面中已存在（已定义）， +则该对象管理会参考配额设置。 这些类型的配额有助于防止存储资源耗尽。例如，用户可能想根据服务器的存储能力来对服务器中 Secret 的数量进行配额限制。 集群中存在过多的 Secret 实际上会导致服务器和控制器无法启动。 @@ -345,10 +354,10 @@ Secret 的数量进行配额限制。 Job 而导致集群拒绝服务。 -对有限的一组资源上实施一般性的对象数量配额也是可能的。 +还有另一种语法仅用于为某些资源设置相同类型的配额。 支持以下类型： @@ -383,10 +392,15 @@ created in a single namespace that are not terminal. You might want to set a `po quota on a namespace to avoid the case where a user creates many small pods and exhausts the cluster's supply of Pod IPs. --> -例如，`pods` 配额统计某个命名空间中所创建的、非终止状态的 `Pod` 个数并确保其不超过某上限值。 +例如，`pods` 配额统计某个命名空间中所创建的、非终止状态的 `pods` 个数并确保其不超过某上限值。 用户可能希望在某命名空间中设置 `pods` 配额，以避免有用户创建很多小的 Pod， 从而耗尽集群所能提供的 Pod IP 地址。 + +你可以在[查看和设置配额](#viewing-and-setting-quotas)节查看更多示例。 + -本示例创建一个配额对象，并将其与具有特定优先级的 Pod 进行匹配。 -该示例的工作方式如下： +本示例创建一个配额对象，并将其与具有特定优先级的 Pod 进行匹配，其工作方式如下： 如果集群运维人员希望默认禁止使用 `namespaces` 和 `namespaceSelector`， -而仅仅允许在特定名字空间中这样做，他们可以将 `CrossNamespacePodAffinity` +而仅仅允许在特定命名空间中这样做，他们可以将 `CrossNamespacePodAffinity` 作为一个被约束的资源。方法是为 `kube-apiserver` 设置标志 `--admission-control-config-file`，使之指向如下的配置文件： @@ -839,9 +852,9 @@ then it requires that every incoming container specifies an explicit limit for t Kubectl supports creating, updating, and viewing quotas: --> -## 查看和设置配额 {#viewing-and-setting-quotas} +## 查看和设置配额 {#viewing-and-setting-quotas} -Kubectl 支持创建、更新和查看配额： +kubectl 支持创建、更新和查看配额： ```shell kubectl create namespace myspace @@ -976,7 +989,7 @@ automatically give each namespace the ability to consume more resources. ## 配额和集群容量 {#quota-and-cluster-capacity} ResourceQuota 与集群资源总量是完全独立的。它们通过绝对的单位来配置。 -所以，为集群添加节点时，资源配额*不会*自动赋予每个命名空间消耗更多资源的能力。 +所以，为集群添加节点时，资源配额**不会**自动赋予每个命名空间消耗更多资源的能力。