2023年6月30日发(作者：)

k8s资源限制——资源的配额管理（ResourceQuotas）简介在k8s集群中为了能够使系统正常稳定运⾏，通常会限制Pod的资源使⽤情况，在k8s集群中如果有⼀个程序出现异常，并占⽤⼤量的系统资源。如果未对该Pod进⾏资源限制的话，可能会影响其他的Pod。k8s常见的资源管理⽅式：计算资源管理(Compute Resources)、资源的配置范围管理(LimitRange)和资源的配额管理(ResourceQuotas)

计算资源管理(Compute Resources): 为Pod中的容器指定使⽤的计算资源(CPU和内存)。

资源的配置范围管理(LimitRange)：可以对集群内Request和Limits的配置做⼀个全局的统⼀的限制，相当于批量设置了某⼀个范围内(某个命名空间)的Pod的资源使⽤限制。

资源的配额管理(Resource Quotas)：可以为每⼀个命名空间(namespace)提供⼀个总体的资源使⽤限制，通过它可以限制命名空间中某个类型的对象的总数⽬上限，也可以设置命名空间中Pod可以使⽤到的计算资源的总上限。资源的配额管理有效解决了多⽤户或多个团队公⽤⼀个k8s集群时资源有效分配的问题。

本篇主要总结 资源的配额管理(Resource Quotas)的使⽤

资源配额，通过 ResourceQuota 对象来定义，对每个命名空间的资源消耗总量提供限制。 它可以限制命名空间中某种类型的对象的总数⽬上限，也可以限制命令空间中的 Pod 可以使⽤的计算资源的总上限。资源配额的⼯作⽅式如下：不同的团队可以在不同的命名空间下⼯作，⽬前这是⾮约束性的，在未来的版本中可能会通过 ACL (Access Control List 访问控制列表) 来实现强制性约束。集群管理员可以为每个命名空间创建⼀个或多个资源配额对象。当⽤户在命名空间下创建资源（如 Pod、Service 等）时，Kubernetes 的配额系统会 跟踪集群的资源使⽤情况，以确保使⽤的资源⽤量不超过资源配额中定义的硬性资源限额。如果资源创建或者更新请求违反了配额约束，那么该请求会报错（HTTP 403 FORBIDDEN）， 并在消息中给出有可能违反的约束。如果命名空间下的计算资源 （如 cpu 和 memory）的配额被启⽤，则⽤户必须为 这些资源设定请求值（request）和约束值（limit），否则配额系统将拒绝 Pod 的创建。 提⽰: 可使⽤ LimitRanger 准⼊控制器来为没有设置计算资源需求的 Pod 设置默认值。

ResourceQuota 对象的名称必须时合法的 。下⾯是使⽤命名空间和配额构建策略的⽰例：在具有 32 GiB 内存和 16 核 CPU 资源的集群中，允许 A 团队使⽤ 20 GiB 内存 和 10 核的 CPU 资源， 允许 B 团队使⽤ 10 GiB内存和 4 核的 CPU 资源，并且预留 2 GiB 内存和 2 核的 CPU 资源供将来分配。限制 "testing" 命名空间使⽤ 1 核 CPU 资源和 1GiB 内存。允许 "production" 命名空间使⽤任意数量。在集群容量⼩于各命名空间配额总和的情况下，可能存在资源竞争。资源竞争时，Kubernetes 系统会遵循先到先得的原则。不管是资源竞争还是配额的修改，都不会影响已经创建的资源使⽤对象。启⽤资源配额资源配额的⽀持在很多 Kubernetes 版本中是默认开启的。当 apiserver --enable-admission-plugins= 参数中包含 ResourceQuota 时，资源配额会被启⽤。当命名空间中存在⼀个 ResourceQuota 对象时，对于该命名空间⽽⾔，资源配额就是开启的。计算资源配额⽤户可以对给定命名空间下的可被请求的 总量进⾏限制。配额机制所⽀持的资源类型：资源名称描述所有⾮终⽌状态的 Pod，其 CPU 限额总量不能超过该值。所有⾮终⽌状态的 Pod，其内存限额总量不能超过该值。所有⾮终⽌状态的 Pod，其 CPU 需求总量不能超过该值。所有⾮终⽌状态的 Pod，其内存需求总量不能超过该值。扩展资源的资源配额除上述资源外，在 Kubernetes 1.10 版本中，还添加了对 的⽀持。由于扩展资源不可超量分配，因此没有必要在配额中为同⼀扩展资源同时指定 requests 和 limits。 对于扩展资源⽽⾔，⽬前仅允许使⽤前缀为 requests. 的配额项。以 GPU 拓展资源为例，如果资源名称为 /gpu，并且要将命名空间中请求的 GPU 资源总数限制为 4，则可以如下定义配额：/gpu: 4有关更多详细信息，请参阅。存储资源配额⽤户可以对给定命名空间下的总量进⾏限制。此外，还可以根据相关的存储类（Storage Class）来限制存储资源的消耗。资源名称epersistentvolumeclaims./e./persistentvolumeclaims描述所有 PVC，存储资源的需求总量不能超过该值。在该命名空间中所允许的 总量。在所有与 storage-class-name 相关的持久卷声明中，存储请求的总和不能超过该值。在与 storage-class-name 相关的所有持久卷声明中，命名空间中可以存在的总数。例如，如果⼀个操作⼈员针对 gold 存储类型与 bronze 存储类型设置配额，操作⼈员可以定义如下配额：/e: /e: 100Gi在 Kubernetes 1.8 版本中，本地临时存储的配额⽀持已经是 Alpha 功能：资源名称ral-storage描述在命名空间的所有 Pod 中，本地临时存储请求的总和不能超过此值。在命名空间的所有 Pod 中，本地临时存储限制值的总和不能超过此值。对象数量配额Kubernetes 1.9 版本增加了使⽤以下语法对所有标准的、命名空间域的资源类型进⾏配额设置的⽀持。count/.这是⽤户可能希望利⽤对象计数配额来管理的⼀组资源⽰例。count/persistentvolumeclaimscount/servicescount/secretscount/configmapscount/replicationcontrollerscount/unt/unt/unt/ount/ount/ionsKubernetes 1.15 版本增加了对使⽤相同语法来约束⾃定义资源的⽀持。 例如，要对 API 组中的⾃定义资源 widgets 设置配额，请使⽤ count/。当使⽤ count/* 资源配额时，如果对象存在于服务器存储中，则会根据配额管理资源。 这些类型的配额有助于防⽌存储资源耗尽。例如，⽤户可能想根据服务器的存储能⼒来对服务器中 Secret 的数量进⾏配额限制。集群中存在过多的 Secret 实际上会导致服务器和控制器⽆法启动！⽤户可以选择对 Job 进⾏配额管理，以防⽌配置不当的 CronJob 在某命名空间中创建太多作业⽽导致集群拒绝服务。在 Kubernetes 1.9 版本之前，可以在有限的⼀组资源上实施⼀般性的对象数量配额。 此外，还可以进⼀步按资源的类型设置其配额。⽀持以下类型：资源名称configmapspersistentvolumlancers描述在该命名空间中允许存在的 ConfigMap 总数上限。在该命名空间中允许存在的 的总数上限。在该命名空间中允许存在的⾮终⽌状态的 pod 总数上限。Pod 终⽌状态等价于 Pod 的 . in (Failed, Succeeded) =true在该命名空间中允许存在的 RC 总数上限。在该命名空间中允许存在的资源配额总数上限。在该命名空间中允许存在的 Service 总数上限。在该命名空间中允许存在的 LoadBalancer 类型的服务总数上限。资源名称rtssecrets描述在该命名空间中允许存在的 NodePort 类型的服务总数上限。在该命名空间中允许存在的 Secret 总数上限。例如，pods 配额统计某个命名空间中所创建的、⾮终⽌状态的 Pod 个数并确保其不超过某上限值。 ⽤户可能希望在某命名空间中设置pods 配额，以避免有⽤户创建很多⼩的 Pod，从⽽耗尽集群所能提供的 Pod IP 地址。配额作⽤域每个配额都有⼀组相关的作⽤域（scope），配额只会对作⽤域内的资源⽣效。 配额机制仅统计所列举的作⽤域的交集中的资源⽤量。当⼀个作⽤域被添加到配额中后，它会对作⽤域相关的资源数量作限制。 如配额中指定了允许（作⽤域）集合之外的资源，会导致验证错误。作⽤域TerminatingNotTerminatingBestEffortNotBestEffort描述匹配所有 DeadlineSeconds 不⼩于 0 的 Pod。匹配所有 DeadlineSeconds 是 nil 的 Pod。匹配所有 Qos 是 BestEffort 的 Pod。匹配所有 Qos 不是 BestEffort 的 Pod。BestEffort` 作⽤域限制配额跟踪以下资源：`podsTerminating、NotTerminating 和 NotBestEffort 这三种作⽤域限制配额跟踪以下资源：基于优先级类（PriorityClass）来设置资源配额FEATURE STATE: Kubernetes 1.12 [beta]Pod 可以创建为特定的。 通过使⽤配额规约中的 scopeSelector 字段，⽤户可以根据 Pod 的优先级控制其系统资源消耗。仅当配额规范中的 scopeSelector 字段选择到某 Pod 时，配额机制才会匹配和计量 Pod 的资源消耗。本⽰例创建⼀个配额对象，并将其与具有特定优先级的 Pod 进⾏匹配。 该⽰例的⼯作⽅式如下：集群中的 Pod 可取三个优先级类之⼀，即 "low"、"medium"、"high"。为每个优先级创建⼀个配额对象。将以下 YAML 保存到⽂件 中。apiVersion: v1kind: Listitems:- apiVersion: v1 kind: ResourceQuota metadata: name: pods-high spec: hard: cpu: "1000" memory: 200Gi pods: "10" scopeSelector: matchExpressions: - operator : In scopeName: PriorityClass values: ["high"]- apiVersion: v1 kind: ResourceQuota metadata: name: pods-medium spec: hard: cpu: "10" memory: 20Gi pods: "10" scopeSelector: matchExpressions: - operator : In scopeName: PriorityClass values: ["medium"]- apiVersion: v1 kind: ResourceQuota metadata: name: pods-low spec: hard: cpu: "5" memory: 10Gi pods: "10" scopeSelector: matchExpressions: - operator : In scopeName: PriorityClass values: ["low"]使⽤ kubectl create 命令运⾏以下操作。kubectl create -f ./ourcequota/pods-high createdresourcequota/pods-medium createdresourcequota/pods-low created使⽤ kubectl describe quota 操作验证配额的 Used 值为 0。kubectl describe quotaName: pods-highNamespace: defaultResource Used Hard-------- ---- ----cpu 0 1kmemory 0 200Gipods 0 10Name: pods-lowNamespace: defaultResource Used Hard-------- ---- ----cpu 0 5memory 0 10Gipods 0 10Name: pods-mediumNamespace: defaultResource Used Hard-------- ---- ----cpu 0 10memory 0 20Gipods 0 10创建优先级为 "high" 的 Pod。 将以下 YAML 保存到⽂件 中。apiVersion: v1kind: Podmetadata: name: high-priorityspec: containers: - name: high-priority image: ubuntu command: ["/bin/sh"] args: ["-c", "while true; do echo hello; sleep 10;done"] resources: requests: memory: "10Gi" cpu: "500m" limits: memory: "10Gi" cpu: "500m" priorityClassName: high使⽤ kubectl create 运⾏以下操作。kubectl create -f ./确认 "high" 优先级配额 pods-high 的 "Used" 统计信息已更改，并且其他两个配额未更改。kubectl describe quotaName: pods-highNamespace: defaultResource Used Hard-------- ---- ----cpu 500m 1kmemory 10Gi 200Gipods 1 10Name: pods-lowNamespace: defaultResource Used Hard-------- ---- ----cpu 0 5memory 0 10Gipods 0 10Name: pods-mediumNamespace: defaultResource Used Hard-------- ---- ----cpu 0 10memory 0 20Gipods 0 10scopeSelector 在 operator 字段中⽀持以下值：InNotInExistDoesNotExist请求与限制分配计算资源时，每个容器可以为 CPU 或内存指定请求和约束。 配额可以针对⼆者之⼀进⾏设置。如果配额中指定了 或 的值，则它要求每个容器都显式给出对这些资源的请求。 同理，如果配额中指定了 或 的值，那么它要求每个容器都显式设定对应资源的限制。查看和设置配额Kubectl ⽀持创建、更新和查看配额：kubectl create namespace myspacecat < iVersion: v1kind: ResourceQuotametadata: name: compute-resourcesspec: hard: : "1" : 1Gi : "2" : 2Gi /gpu: 4EOFkubectl create -f ./ --namespace=myspacecat < iVersion: v1kind: ResourceQuotametadata: name: object-countsspec: hard: configmaps: "10" persistentvolumeclaims: "4" pods: "4" replicationcontrollers: "20" secrets: "10" services: "10" lancers: "2"EOFkubectl create -f ./ --namespace=myspacekubectl get quota --namespace=myspaceNAME AGEcompute-resources 30sobject-counts 32skubectl describe quota compute-resources --namespace=myspaceName: compute-resourcesNamespace: myspaceResource Used Hard-------- ---- ---- 0 0 0 0 /gpu 0 4kubectl describe quota object-counts --namespace=myspaceName: object-countsNamespace: myspaceResource Used Hard-------- ---- ----configmaps 0 10persistentvolumeclaims 0 4pods 0 4replicationcontrollers 0 20secrets 1 10services 0 lancers 0 2kubectl 还使⽤语法 count/. ⽀持所有标准的、命名空间域的资源的对象计数配额：kubectl create namespace myspacekubectl create quota test --hard=count/ions=2,count/ions=4,count/pods=3,count/secrets=4 --namespace=myspacekubectl create deployment nginx --image=nginx --namespace=myspacekubectl describe quota --namespace=myspaceName: testNamespace: myspaceResource Used Hard-------- ---- ----count/ions 1 2count/pods 2 3count/ions 1 4count/secrets 1 4配额和集群容量资源配额与集群资源总量是完全独⽴的。它们通过绝对的单位来配置。 所以，为集群添加节点时，资源配额不会⾃动赋予每个命名空间消耗更多资源的能⼒。有时可能需要资源配额⽀持更复杂的策略，⽐如：在⼏个团队中按⽐例划分总的集群资源。允许每个租户根据需要增加资源使⽤量，但要有⾜够的限制以防⽌资源意外耗尽。探测某个命名空间的需求，添加物理节点并扩⼤资源配额值。这些策略可以通过将资源配额作为⼀个组成模块、⼿动编写⼀个控制器来监控资源使⽤情况， 并结合其他信号调整命名空间上的硬性资源配额来实现。注意：资源配额对集群资源总体进⾏划分，但它对节点没有限制：来⾃不同命名空间的 Pod 可能在同⼀节点上运⾏。默认情况下限制特定优先级的资源消耗有时候可能希望当且仅当某名字空间中存在匹配的配额对象时，才可以创建特定优先级 （例如 "cluster-services"）的 Pod。通过这种机制，操作⼈员能够将限制某些⾼优先级类仅出现在有限数量的命名空间中， ⽽并⾮每个命名空间默认情况下都能够使⽤这些优先级类。要实现此⽬的，应使⽤ kube-apiserver 标志 --admission-control-config-file 传递如下配置⽂件的路径：apiVersion: /v1kind: AdmissionConfigurationplugins:- name: "ResourceQuota" configuration: apiVersion: /v1 kind: ResourceQuotaConfiguration limitedResources: - resource: pods matchScopes: - scopeName: PriorityClass operator: In values: ["cluster-services"]现在，仅当命名空间中存在匹配的 scopeSelector 的配额对象时，才允许使⽤ "cluster-services" Pod。⽰例： scopeSelector: matchExpressions: - scopeName: PriorityClass operator: In values: ["cluster-services"]