当多个用户或团队共享具有固定数目节点的集群时,人们会担心有人使用的资源超出应有的份额。
资源配额是帮助管理员解决这一问题的工具。
资源配额, 通过 ResourceQuota
对象来定义, 对每个namespace的资源消耗总量提供限制。 它可以按类型限制namespace下可以创建的对象的数量,也可以限制可被该项目以资源形式消耗的计算资源的总量。
资源配额的工作方式如下:
403 FORBIDDEN
,以及说明违反配额
约束的信息。cpu
和 memory
)的配额被启用,则用户必须为这些资源设定请求值(request)
和约束值(limit),否则配额系统将拒绝Pod的创建。
提示: 可使用 LimitRange 准入控制器来为没有设置计算资源需求的Pod设置默认值。
作为示例,请参考 演练 来避免这个问题。下面是使用namespace和配额构建策略的示例:
在集群容量小于各namespace配额总和的情况下,可能存在资源竞争。 Kubernetes采用先到先服务的方式处理这类问题。
无论是资源竞争还是配额的变更都不会影响已经创建的资源。
资源配额的支持在很多Kubernetes版本中是默认开启的。 当 apiserver 的
--admission-control=
参数中包含 ResourceQuota
时,资源配额会被启用。
当namespace中存在一个 ResourceQuota
对象时,该namespace即开始实施资源配额管理。
一个namespace中最多只应存在一个 ResourceQuota
对象
用户可以对给定namespace下的 计算资源 总量进行限制。
配额机制所支持的资源类型:
资源名称 | 描述 |
---|---|
cpu |
所有非终止状态的Pod中,其CPU需求总量不能超过该值。 |
limits.cpu |
所有非终止状态的Pod中,其CPU限额总量不能超过该值。 |
limits.memory |
所有非终止状态的Pod中,其内存限额总量不能超过该值。 |
memory |
所有非终止状态的Pod中,其内存需求总量不能超过该值。 |
requests.cpu |
所有非终止状态的Pod中,其CPU需求总量不能超过该值。 |
requests.memory |
所有非终止状态的Pod中,其内存需求总量不能超过该值。 |
用户可以对给定namespace下的 存储资源 总量进行限制。
此外,还可以根据相关的存储类(Storage Class)来限制存储资源的消耗。
资源名称 | 描述 |
---|---|
requests.storage |
所有的PVC中,存储资源的需求不能超过该值。 |
persistentvolumeclaims |
namespace中所允许的 PVC 总量。 |
<storage-class-name>.storageclass.storage.k8s.io/requests.storage |
所有该storage-class-name相关的PVC中, 存储资源的需求不能超过该值。 |
<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims |
namespace中所允许的该storage-class-name相关的PVC的总量。 |
例如,如果一个操作人员针对 “黄金” 存储类型与 “铜” 存储类型设置配额,操作员可以 定义配额如下:
gold.storageclass.storage.k8s.io/requests.storage: 500Gi
bronze.storageclass.storage.k8s.io/requests.storage: 100Gi
给定类型的对象数量可以被限制。 支持以下类型:
资源名称 | 描述 |
---|---|
configmaps |
namespace下允许存在的configmap的数量。 |
persistentvolumeclaims |
namespace下允许存在的PVC的数量。 |
pods |
namespace下允许存在的非终止状态的pod数量。 如果pod 的 status.phase 为 Failed 或 Succeeded , 那么其处于终止状态。 |
replicationcontrollers |
namespace下允许存在的replication controllers的数量。 |
resourcequotas |
namespace下允许存在的 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地址。
每个配额都有一组相关的作用域(scope),配额只会对作用域内的资源生效。
当一个作用域被添加到配额中后,它会对作用域相关的资源数量作限制。 如配额中指定了允许(作用域)集合之外的资源,会导致验证错误。
范围 | 描述 |
---|---|
Terminating |
匹配 spec.activeDeadlineSeconds >= 0 的pod。 |
NotTerminating |
匹配 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
分配计算资源时,每个容器可以为CPU或内存指定请求和约束。 也可以设置两者中的任何一个。
如果配额中指定了 requests.cpu
或 requests.memory
的值,那么它要求每个进来的容器针对这些资源有明确的请求。 如果配额中指定了 limits.cpu
或 limits.memory
的值,那么它要求每个进来的容器针对这些资源指定明确的约束。
Kubectl 支持创建、更新和查看配额:
$ kubectl create namespace myspace
$ cat <<EOF > compute-resources.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
name: compute-resources
spec:
hard:
pods: "4"
requests.cpu: "1"
requests.memory: 1Gi
limits.cpu: "2"
limits.memory: 2Gi
EOF
$ kubectl create -f ./compute-resources.yaml --namespace=myspace
$ cat <<EOF > object-counts.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
name: object-counts
spec:
hard:
configmaps: "10"
persistentvolumeclaims: "4"
replicationcontrollers: "20"
secrets: "10"
services: "10"
services.loadbalancers: "2"
EOF
$ kubectl create -f ./object-counts.yaml --namespace=myspace
$ kubectl get quota --namespace=myspace
NAME AGE
compute-resources 30s
object-counts 32s
$ 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
$ 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
配额对象是独立于集群容量的。它们通过绝对的单位来表示。 所以,为集群添加节点, 不会 自动赋予每个namespace消耗更多资源的能力。
有时可能需要更复杂的策略,比如:
这些策略可以基于 ResourceQuota,通过编写一个检测配额使用,并根据其他信号调整各namespace下的配额硬性限制的 “控制器” 来实现。
注意:资源配额对集群资源总体进行划分,但它对节点没有限制:来自多个namespace的Pod可能在同一节点上运行。
查看 如何使用资源配额的详细示例。
查看 资源配额设计文档 了解更多信息。
此页是否对您有帮助?
感谢反馈。如果您有一个关于如何使用 Kubernetes 的特定的、需要答案的问题,可以访问 Stack Overflow. 在 GitHub 仓库上登记新的问题 报告问题 或者 提出改进建议.