1, 资源配额概述
当存在多个用户或团队共享数目国定的集群时, 就需要考虑如果有人使用的资源可能会超出应有的份额带来的问题, 资源配额 (ResourceQuota) 就是用来帮助集群管理员解决上述问题的工具. 在 Kubernetes 集群中通过 ResourceQuota 对象定义每个命名空间 (namespace) 的资源配额, 从而实现资源消耗总量的限制. 资源配额有两个作用: 1)可以按类型限制命名空间 (namespace) 下所创建对象的数量; 2)限制所消耗计算资源的总量.
资源配额的工作方式如下:
不同的团队在不同的命名空间下工作. 目前这是是非必须的, 后续计划通过 ACL (Access Control List 访问控制列表) 使其变为强制性的.
集群管理员为每个命名空间创建一个或多个资源配额对象.
用户在命名空间下创建资源 (pods, services 等), 同时配额系统会跟踪使用情况, 来确保其不超过 资源配额中定义的硬性资源限额.
如果资源的创建或更新违反了配额约束, 则请求会失败, 并返回 HTTP 状态码 403 FORBIDDEN , 以及说明违反配额 约束的信息.
如果命名空间下的计算资源 (如 CPU 和 memory)的配额被启用, 则用户必须为这些资源设定请求值(request) 和约束值(limit), 否则配额系统将拒绝 Pod 的创建.
提示: 可使用 LimitRange 准入控制器来为没有设置计算资源需求的 Pod 设置默认值. 作为示例, 请参考 演练 来避免这个问题.
下面是使用命名空间和配额构建策略的示例:
在具有 32 GiB 内存 和 16 核 CPU 资源的集群中, 允许 A 团队使用 20 GiB 内存 和 10 核的 CPU 资源, 允许 B 团队使用 10GiB 内存和 4 核的 CPU 资源, 并且预留 2GiB 内存和 2 核的 CPU 资源供将来分配.
限制 "testing" 命名空间使用 1 核 CPU 资源和 1GiB 内存. 允许 "production" 命名空间使用任意数量.
在集群容量小于各命名空间配额总和的情况下, 可能存在资源竞争. Kubernetes 采用先到先服务的方式处理这类问题. 无论是资源竞争还是配额的变更都不会影响已经创建的资源. 资源配额的支持在很多 Kubernetes 版本中是默认开启的. 当 apiserver 的 --admission-control= 参数中包含 ResourceQuota 时, 资源配额会被启用. 当 namespace 中存在一个 ResourceQuota 对象时, 该 namespace 即开始实施资源配额管理. 一个 namespace 中最多只应存在一个 ResourceQuota 对象
2, 资源配额所能管理的资源类型
在 Kuberners 中, 资源配额能够对计算资源(CPU 和内存), 存储资源, 以及对资源对象的数量进行管理.
2.1 计算资源配额
用户可以对给定命名空间下的 计算资源 总量进行限制. 配额机制所支持的资源类型:
资源名称 | 描述 |
---|---|
cpu | 所有非终止状态的 Pod 中,其 CPU 需求总量不能超过该值。 |
limits.cpu | 所有非终止状态的 Pod 中,其 CPU 限额总量不能超过该值。 |
limits.memory | 所有非终止状态的 Pod 中,其内存限额总量不能超过该值。 |
memory | 所有非终止状态的 Pod 中,其内存需求总量不能超过该值。 |
requests.cpu | 所有非终止状态的 Pod 中,其 CPU 需求总量不能超过该值。 |
requests.memory | 所有非终止状态的 Pod 中,其内存需求总量不能超过该值。 |
2.2 存储资源配额
用户可以对给定命名空间下的存储资源总量进行限制. 此外, 还可以根据相关的存储类 (Storage Class) 来限制存储资源的消耗.
资源名称 | 描述 |
---|---|
requests.storage | 所有的 PVC 中,存储资源的需求不能超过该值。 |
persistentvolumeclaims | namespace 中所允许的 & nbsp;PVC 总量。 |
所有该 storage-class-name 相关的 PVC 中, 存储资源的需求不能超过该值。 | |
namespace 中所允许的该 storage-class-name 相关的 PVC 的总量。 |
例如, 如果一个操作人员针对 "黄金" 存储类型与 "铜" 存储类型设置配额, 操作员可以 定义配额如下:
- gold.storageclass.storage.k8s.io/requests.storage: 500Gi
- bronze.storageclass.storage.k8s.io/requests.storage: 100Gi
2.3 对象数量配额
给定类型的对象数量可以被限制. 支持以下类型:
资源名称 | 描述 |
---|---|
configmaps | namespace 下允许存在的 configmap 的数量。 |
persistentvolumeclaims | namespace 下允许存在的 PVC 的数量。 |
pods | namespace 下允许存在的非终止状态的 pod 数量。 如果 pod 的 & nbsp;status.phase 为 Failed 或 Succeeded , 那么其处于终止状态。 |
replicationcontrollers | namespace 下允许存在的 replication controllers 的数量。 |
resourcequotas | namespace 下允许存在的 & nbsp;resource quotas 的数量。 |
services | namespace 下允许存在的 service 的数量。 |
services.loadbalancers | namespace 下允许存在的 load balancer 类型的 service 的数量。 |
services.nodeports | namespace 下允许存在的 node port 类型的 service 的数量。 |
secrets | namespace 下允许存在的 secret 的数量。 |
例如 pods 配额统计并保证单个 namespace 下创建 pods 的最大数量. 用户可能希望在 namespace 中为 pod 设置配额, 来避免有用户创建很多小的 pod, 从而耗尽集群提供的 pod IP 地址.
3, 配额作用域
每个配额都有一组相关的作用域 (scope), 配额只会对作用域内的资源生效. 当一个作用域被添加到配额中后, 它会对作用域相关的资源数量作限制. 如配额中指定了允许(作用域) 集合之外的资源, 会导致验证错误.
范围 | 描述 |
---|---|
Terminating | 匹配 & nbsp;spec.activeDeadlineSeconds >= 0 的 pod。 |
NotTerminating | 匹配 & nbsp;spec.activeDeadlineSeconds is nil 的 pod。 |
BestEffort | 匹配” 尽力而为(best effort)“服务类型的 pod。 |
NotBestEffort | 匹配非” 尽力而为(best effort)“服务类型的 pod。 |
BestEffort 作用域限制配额跟踪以下资源: pods
Terminating, NotTerminating 和 NotBestEffort 限制配额跟踪以下资源:
- CPU
- limits.CPU
- limits.memory
- memory
- pods
- requests.CPU
- requests.memory
4, 设置和查看资源配额示例
由于在资源配额是基于命名空间进行设置的, 因此, 在此示例中先创建一个名称为 myspace 的命名空间:
$ kubectl create namespace myspace
4.1 计算资源管理
下面是定义管理计算资源配额的 YAML 文件, 在此文件中, 资源配额管理的名称为 computer-resources,pod 的数量为 4,CPU 的需求数量为 1 核, CPU 的限制数量为 2 核; 内存的需求大小为 1Gi, 内存的限制大小为 2Gi.
- apiVersion: v1
- kind: ResourceQuota
- metadata:
- name: compute-resources
- spec:
- hard:
- pods: "4"
- requests.CPU: "1"
- requests.memory: 1Gi
- limits.CPU: "2"
- limits.memory: 2Gi
通过下面的 kubectl 命令在 myspaces 命名空间下创建资源配额:
$ kubectl create -f ./compute-resources.YAML --namespace=myspace
在创建完资源配额后, 通过执行下面的命令查看资源配额的详细信息:
- $ kubectl describe quota compute-resources --namespace=myspace
- Name: compute-resources
- Namespace: myspace
- Resource Used Hard
- -------- ---- ----
- limits.CPU 0 2
- limits.memory 0 2Gi
- pods 0 4
- requests.CPU 0 1
- requests.memory 0 1Gi
4.1 资源对象数量管理
下面是定义管理资源对象数量配额的 YAML 文件, 在此文件中, 资源配额管理的名称为 object-counts:
- apiVersion: v1
- kind: ResourceQuota
- metadata:
- name: object-counts
- spec:
- hard:
- configmaps: "10"
- persistentvolumeclaims: "4"
- replicationcontrollers: "20"
- secrets: "10"
- services: "10"
- services.loadbalancers: "2"
通过下面的 kubectl 命令在 myspaces 命名空间下创建资源配额:
$ kubectl create -f ./object-counts.YAML --namespace=myspace
在创建完资源配额后, 通过执行下面的命令查看资源配额的详细信息:
- $ kubectl describe quota object-counts --namespace=myspace
- Name: object-counts
- Namespace: myspace
- Resource Used Hard
- -------- ---- ----
- configmaps 0 10
- persistentvolumeclaims 0 4
- replicationcontrollers 0 20
- secrets 1 10 services 0 10
- services.loadbalancers 0 2
参考资料:
1.《资源配额》地址: https://kubernetes.io/zh/docs/concepts/policy/resource-quotas/
作者简介:
季向远, 北京神舟航天软件技术有限公司. 本文版权归原作者所有.
来源: https://juejin.im/entry/5c0a4d8a51882515951279b1