Kubernetes 资源配额、限制范围【ResourceQuote、LimitRange】

云原生 从docker、Jenkins、Kubernetes从入门到精通系列

1.ResourceQuote 资源配额

1. 简介

当多个用户或团队共享具有固定节点数目的集群时，人们会担心有人使用超过其基于公平原则所分配到的资源量。

资源配额是帮助管理员解决这一问题的工具。

资源配额，通过 ResourceQuota 对象来定义，对每个命名空间的资源消耗总量提供限制。 它可以限制命名空间中某种类型的对象的总数目上限，也可以限制命名空间中的 Pod 可以使用的计算资源的总上限。

资源配额的工作方式如下：

• 不同的团队可以在不同的命名空间下工作。这可以通过 RBAC 强制执行。
• 集群管理员可以为每个命名空间创建一个或多个 ResourceQuota 对象。
• 当用户在命名空间下创建资源（如 Pod、Service 等）时，Kubernetes 的配额系统会跟踪集群的资源使用情况， 以确保使用的资源用量不超过 ResourceQuota 中定义的硬性资源限额。
• 如果资源创建或者更新请求违反了配额约束，那么该请求会报错（HTTP 403 FORBIDDEN）， 并在消息中给出有可能违反的约束。
• 如果命名空间下的计算资源 （如 cpu 和 memory）的配额被启用， 则用户必须为这些资源设定请求值（request）和约束值（limit），否则配额系统将拒绝 Pod 的创建。 提示: 可使用 LimitRanger 准入控制器来为没有设置计算资源需求的 Pod 设置默认值。

2. 实战测试

vi resource-quota.yaml

kubectl apply -f resource-quota.yaml -n hello

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
spec:
  hard:
    requests.cpu: "1"
    requests.memory: 1Gi
    limits.cpu: "2"
    limits.memory: 2Gi
    requests.nvidia.com/gpu: 4

3. 计算资源配额

用户可以对给定命名空间下的可被请求的 计算资源 总量进行限制。

配额机制所支持的资源类型：

资源名称	描述
limits.cpu	所有非终止状态的 Pod，其 CPU 限额总量不能超过该值。
limits.memory	所有非终止状态的 Pod，其内存限额总量不能超过该值。
requests.cpu	所有非终止状态的 Pod，其 CPU 需求总量不能超过该值。
requests.memory	所有非终止状态的 Pod，其内存需求总量不能超过该值。
hugepages-<size>	对于所有非终止状态的 Pod，针对指定尺寸的巨页请求总数不能超过此值。
cpu	与 requests.cpu 相同。
memory	与 requests.memory 相同。

4. 存储资源配额

用户可以对给定命名空间下的存储资源 总量进行限制。

此外，还可以根据相关的存储类（Storage Class）来限制存储资源的消耗。

资源名称	描述
requests.storage	所有 PVC，存储资源的需求总量不能超过该值。
persistentvolumeclaims	在该命名空间中所允许的 PVC 总量。
<storage-class-name>.storageclass.storage.k8s.io/requests.storage	在所有与 <storage-class-name> 相关的持久卷申领中，存储请求的总和不能超过该值。
<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims	在与 storage-class-name 相关的所有持久卷申领中，命名空间中可以存在的持久卷申领总数。

例如，如果一个操作人员针对 gold 存储类型与 bronze 存储类型设置配额， 操作人员可以定义如下配额：

• gold.storageclass.storage.k8s.io/requests.storage: 500Gi
• bronze.storageclass.storage.k8s.io/requests.storage: 100Gi

在 Kubernetes 1.8 版本中，本地临时存储的配额支持已经是 Alpha 功能：

资源名称	描述
requests.ephemeral-storage	在命名空间的所有 Pod 中，本地临时存储请求的总和不能超过此值。
limits.ephemeral-storage	在命名空间的所有 Pod 中，本地临时存储限制值的总和不能超过此值。
ephemeral-storage	与 requests.ephemeral-storage 相同。

5. 对象数量配额

你可以使用以下语法对所有标准的、命名空间域的资源类型进行配额设置：

• count/<resource>.<group>：用于非核心（core）组的资源
• count/<resource>：用于核心组的资源

这是用户可能希望利用对象计数配额来管理的一组资源示例。

• count/persistentvolumeclaims
• count/services
• count/secrets
• count/configmaps
• count/replicationcontrollers
• count/deployments.apps
• count/replicasets.apps
• count/statefulsets.apps
• count/jobs.batch
• count/cronjobs.batch

相同语法也可用于自定义资源。 例如，要对 example.com API 组中的自定义资源 widgets 设置配额，请使用 count/widgets.example.com。

当使用 count/* 资源配额时，如果对象存在于服务器存储中，则会根据配额管理资源。 这些类型的配额有助于防止存储资源耗尽。例如，用户可能想根据服务器的存储能力来对服务器中 Secret 的数量进行配额限制。 集群中存在过多的 Secret 实际上会导致服务器和控制器无法启动。 用户可以选择对 Job 进行配额管理，以防止配置不当的 CronJob 在某命名空间中创建太多 Job 而导致集群拒绝服务。

对有限的一组资源上实施一般性的对象数量配额也是可能的。

支持以下类型：

资源名称	描述
configmaps	在该命名空间中允许存在的 ConfigMap 总数上限。
persistentvolumeclaims	在该命名空间中允许存在的 PVC 的总数上限。
pods	在该命名空间中允许存在的非终止状态的 Pod 总数上限。Pod 终止状态等价于 Pod 的 .status.phase in (Failed, Succeeded) 为真。
replicationcontrollers	在该命名空间中允许存在的 ReplicationController 总数上限。
resourcequotas	在该命名空间中允许存在的 ResourceQuota 总数上限。
services	在该命名空间中允许存在的 Service 总数上限。
services.loadbalancers	在该命名空间中允许存在的 LoadBalancer 类型的 Service 总数上限。
services.nodeports	在该命名空间中允许存在的 NodePort 类型的 Service 总数上限。
secrets	在该命名空间中允许存在的 Secret 总数上限。

例如，pods 配额统计某个命名空间中所创建的、非终止状态的 Pod 个数并确保其不超过某上限值。 用户可能希望在某命名空间中设置 pods 配额，以避免有用户创建很多小的 Pod， 从而耗尽集群所能提供的 Pod IP 地址。

6. 优先级

Pod 可以创建为特定的优先级。 通过使用配额规约中的 scopeSelector 字段，用户可以根据 Pod 的优先级控制其系统资源消耗。

仅当配额规范中的 scopeSelector 字段选择到某 Pod 时，配额机制才会匹配和计量 Pod 的资源消耗。

如果配额对象通过 scopeSelector 字段设置其作用域为优先级类， 则配额对象只能跟踪以下资源：

• pods
• cpu
• memory
• ephemeral-storage
• limits.cpu
• limits.memory
• limits.ephemeral-storage
• requests.cpu
• requests.memory
• requests.ephemeral-storage

2.LimitRange 限制范围

1. 简介

默认情况下， Kubernetes 集群上的容器运行使用的计算资源没有限制。 使用 Kubernetes 资源配额， 管理员（也称为 集群操作者）可以在一个指定的命名空间内限制集群资源的使用与创建。 在命名空间中，一个 Pod 最多能够使用命名空间的资源配额所定义的 CPU 和内存用量。 作为集群操作者或命名空间级的管理员，你可能也会担心如何确保一个 Pod 不会垄断命名空间内所有可用的资源。

LimitRange 是限制命名空间内可为每个适用的对象类别 （例如 Pod 或 PersistentVolumeClaim） 指定的资源分配量（限制和请求）的策略对象。

一个 LimitRange（限制范围）  对象提供的限制能够做到：

• 在一个命名空间中实施对每个 Pod 或 Container 最小和最大的资源使用量的限制。
• 在一个命名空间中实施对每个 PersistentVolumeClaim 能申请的最小和最大的存储空间大小的限制。
• 在一个命名空间中实施对一种资源的申请值和限制值的比值的控制。
• 设置一个命名空间中对计算资源的默认申请/限制值，并且自动的在运行时注入到多个 Container 中。

当某命名空间中有一个 LimitRange 对象时，将在该命名空间中实施 LimitRange 限制。

LimitRange 的名称必须是合法的 DNS 子域名。

2. 实战测试

限制名称空间，加上namespace：hello

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