资源配额

默认情况下，容器在 Kubernetes 集群上以无界限的 计算资源 运行。使用 Kubernetes 资源配额，管理员（也称为集群操作员）可以限制在指定 命名空间 内的集群资源（如 CPU 时间、内存和持久性存储）的消耗和创建。在命名空间内，Pod 可以消耗与应用于该命名空间的 ResourceQuotas 允许的 CPU 和内存一样多的资源。作为集群操作员或命名空间级管理员，您可能还担心确保单个对象不会垄断命名空间内所有可用资源。

LimitRange 是一种策略，用于约束您可以在命名空间中为每个适用的对象类型（如 Pod 或 PersistentVolumeClaim）指定的资源分配（限制和请求）。

LimitRange 提供了可以执行以下操作的约束：

• 强制执行命名空间中每个 Pod 或容器的最小和最大计算资源使用量。
• 强制执行命名空间中每个 PersistentVolumeClaim 的最小和最大存储请求。
• 强制执行命名空间中资源的请求与限制之间的比率。
• 在命名空间中设置计算资源的默认请求/限制，并在运行时自动将其注入到容器中。

当命名空间中存在 LimitRange 对象时，LimitRange 在该特定命名空间中强制执行。

LimitRange 对象的名称必须是有效的 DNS 子域名。

对资源限制和请求的约束

• 管理员在命名空间中创建 LimitRange。
• 用户在该命名空间中创建（或尝试创建）对象，例如 Pod 或 PersistentVolumeClaims。
• 首先，LimitRange 准入控制器将所有未设置计算资源需求的 Pod（及其容器）应用默认请求和限制值。
• 其次，LimitRange 跟踪使用情况以确保它不会超过命名空间中存在的任何 LimitRange 中定义的资源最小值、最大值和比率。
• 如果您尝试创建或更新违反 LimitRange 约束的对象（Pod 或 PersistentVolumeClaim），您对 API 服务器的请求将失败，并返回 HTTP 状态码 403 Forbidden 和一条解释已违反的约束的消息。
• 如果您在命名空间中添加应用于计算相关资源（如 cpu 和 memory）的 LimitRange，则必须为这些值指定请求或限制。否则，系统可能会拒绝 Pod 创建。
• LimitRange 验证仅在 Pod 准入阶段发生，而不是在运行的 Pod 上发生。如果您添加或修改 LimitRange，则该命名空间中已存在的 Pod 会保持不变。
• 如果命名空间中存在两个或多个 LimitRange 对象，则无法确定将应用哪个默认值。

LimitRange 和 Pod 的准入检查

LimitRange 不检查它应用的默认值的 一致性。这意味着 LimitRange 设置的限制的默认值可能小于客户端提交给 API 服务器的规范中为容器指定的请求值。如果发生这种情况，最终的 Pod 将无法调度。

例如，您使用以下清单定义一个 LimitRange

concepts/policy/limit-range/problematic-limit-range.yaml

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-resource-constraint
spec:
  limits:
  - default: # this section defines default limits
      cpu: 500m
    defaultRequest: # this section defines default requests
      cpu: 500m
    max: # max and min define the limit range
      cpu: "1"
    min:
      cpu: 100m
    type: Container

以及一个声明了 700m 的 CPU 资源请求，但没有限制的 Pod

concepts/policy/limit-range/example-conflict-with-limitrange-cpu.yaml

apiVersion: v1
kind: Pod
metadata:
  name: example-conflict-with-limitrange-cpu
spec:
  containers:
  - name: demo
    image: registry.k8s.io/pause:2.0
    resources:
      requests:
        cpu: 700m

然后，该 Pod 将无法调度，并出现类似以下错误：

Pod "example-conflict-with-limitrange-cpu" is invalid: spec.containers[0].resources.requests: Invalid value: "700m": must be less than or equal to cpu limit

如果您同时设置了 request 和 limit，则即使在同一个 LimitRange 生效的情况下，新的 Pod 也将成功调度

concepts/policy/limit-range/example-no-conflict-with-limitrange-cpu.yaml

apiVersion: v1
kind: Pod
metadata:
  name: example-no-conflict-with-limitrange-cpu
spec:
  containers:
  - name: demo
    image: registry.k8s.io/pause:2.0
    resources:
      requests:
        cpu: 700m
      limits:
        cpu: 700m

资源约束示例

使用 LimitRange 可以创建的策略示例：

• 在具有 8 GiB RAM 和 16 个内核的 2 节点集群中，将命名空间中的 Pod 限制为请求 100m 的 CPU，CPU 的最大限制为 500m，内存的请求为 200Mi，内存的最大限制为 600Mi。
• 为在规范中没有设置 cpu 和内存请求的容器启动的容器定义 150m 的默认 CPU 限制和请求，以及 300Mi 的默认内存请求。

在命名空间的总限制小于 Pod/容器的限制总和的情况下，可能会出现资源争用。在这种情况下，容器或 Pod 不会创建。

争用或对 LimitRange 的更改不会影响已创建的资源。

下一步

有关使用限制的示例，请参阅：

• 如何配置每个命名空间的最小和最大 CPU 约束.
• 如何配置每个命名空间的最小和最大内存约束.
• 如何配置每个命名空间的默认 CPU 请求和限制.
• 如何配置每个命名空间的默认内存请求和限制.
• 如何配置每个命名空间的最小和最大存储使用量.
• 有关配置每个命名空间的配额的详细示例。

有关上下文和历史信息，请参阅 LimitRanger 设计文档。