限制命名空间中的可用资源总量

ResourceQuota 资源介绍

LimitRanger 插件会强制执行 LimitRange 资源中配置的策略。类似地，ResourceQuota 的接纳控制插件会检查将要创建的 pod 是否会引起总资源量超出 ResourceQuota。如果那样，创建请求会被拒绝。因为资源配额在 pod 创建时进行检查，所以 ResourceQuota 对象仅仅作用于在其后创建的 pod —— 并不影响已经存在的 pod。
资源配额限制了一个命名空间中 pod 和 PVC 存储最多可以使用的资源总址。同时也可以限制用户允许在该命名空间中创建 pod、PVC，以及其他 API 对象的数量，因为到目前为止我们处理最多的资源是 CPU 和内存，下面就来看看如何为这两种资源指定配额。

为CPU和内存创建 ResourceQuota

cat quota-cpu-memory.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: cpu-and-mem
spec:
  hard:
    requests.cpu: 400m
    requests.memory: 200Mi
    limits.cpu: 600m
    limits.memory: 500Mi
	
# kubectl  get ResourceQuota -A 
NAMESPACE   NAME          AGE   REQUEST                                                LIMIT
default     cpu-and-mem   7s    requests.cpu: 100m/400m, requests.memory: 10Mi/200Mi   limits.cpu: 200m/600m, limits.memory: 100Mi/500Mi

这个 ResourceQuota 设置了命名空间中所有 pod 最多可申请的 CPU 数量为400毫核，limits 最大总量为600毫核。对于内存，设置所有 requests 最大总量为200MiB, limits为500MiB。

与 LimitRange 一样，ResourceQuota 对象应用于它所创建的那个命名空间，但不同的是，后者可以限制所有 pod 资源 requests 和 limits 的总量，而不是每个单独的 pod 或者容器。

查看配额和配额使用情况
将 ResourceQuota 对象提交至 API 服务器之后，可以执行 kubectl describe 命令查看当前配额已经使用了多少

[root@master limit]# kubectl describe quota 
Name:            cpu-and-mem
Namespace:       default
Resource         Used   Hard
--------         ----   ----
limits.cpu       200m    600m
limits.memory     100Mi   500Mi
requests.cpu      100m    400m
requests.memory    10Mi    200Mi

与ResourceQuota 同时创建 LimitRange
需要注意的一点是，创建 ResourceQuota 时往往还需要随之创建一个 LimitRange 对象。
假设我们没有配置 LimitRange ， kubia-manual pod将无法成功创建，因为它没有指定任何资源requests和limits。

[root@master ]# kubectl  create -f kubia-manual.yaml 
Error from server (Forbidden): error when creating "kubia-manual.yaml": pods "kubia-manual" is forbidden: failed quota: cpu-and-mem: must specify limits.cpu,limits.memory,requests.cpu,requests.memory

因此，当特定资源(CPU或内存）配置了(requests或limits) 配额，在 pod 中必须为这些资源（分别）指定 requests limits ，否则 API 服务器不会接收该 pod的创建请求。

为持久化存储指定配额

ResourceQuota 对象同样可以限制某个命名空间中最多可声明的持久化存储总量

cat quota-storage.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: storage
spec:
  hard:
    requests.storage: 500Gi            # 可申明存储总量
    ssd.storageclass.storage.k8s.io/requests.storage: 300Gi
    standard.storageclass.storage.k8s.io/requests.storage: 1Ti

Namespace 中所有可申请的 PVC 总量被限制为 500GiB （通过配额对象中的 requests.storag ）。
PVC 可以申请一个特定 StorageClass 、动态提供的 PV (Persistent Volume)。这就是为什么 Kubrnetes 同样允许单独为 StorageClass 提供定义存储配额原因。
限制了可声明 SSD 存储（以 ssd 命名的 StorageClass ）的总量为 300GiB。
低性能的 HDD 存储 ( StorageClass standrad ) 限制为 1TiB。

限制可创建对象的个数

资源配额同样可以限制单个命名空间中的 pod 、ReplicationController、 Service 以及其他对象的个数。

cat quota-object-count.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: objects
spec:
  hard:
    pods: 10
    replicationcontrollers: 5
    secrets: 10
    configmaps: 10
    persistentvolumeclaims: 5
    services: 5
    services.loadbalancers: 1
    services.nodeports: 2
    ssd.storageclass.storage.k8s.io/persistentvolumeclaims: 2  # 最多s声明2个 StorageClass 为 ssd 的PVC

上面的例子允许用户在命名空间中最多创建10个 pod ，无论是于动创建还是通 ReplicationController、 ReplicaSet、 DaemonSet、 Job 创建的。
同时限制了ReplicationController 最大个数为 5, Service 最大个数为，其中 LoadBalancer 类型最多 1个， NotPort 类型最多2个。
与通过指定每个 StorageClass 来限制存储资源的申请总量类似， PVC 的个数同样可以按照 StorageClass 来限制。

对象个数配额目前可以为以下对象配置：
• pod
• ReplicationController
• Secret
• ConfigMap
• Persistent Volume Claim
• Service
Service （通用）及两种特定类型的 Service ，比如 LoadBalancerService (services . loadbalancers ）和 NodePort Service (services . nodeports)

为特定的 pod 状态或者 QoS 等级指定配额

Quota 可以被 quota scopes 限制，目前配额作用范围共有4 种：

BestEffort
NotBestEffort
Termination
NotTerminating
BestEffort 和 NotBestEffort 范围决定配额是否应用于 BestEffort QoS 级或者其他两种等级（ Burstablequota-scoped.yaml 和 Guaranteed）的 pod。

Termination 和 NotTerminatingo

通过在 pod spec 中配置 activeDeadlineSeconds 。该属性定义了一个 pod 从开始尝试停止的时间到其被标记为 Failed 然后真正停止之前，允许其在节点上继续运行的秒数。

Terminating 配额作用范围应用于这些配置了 activeDeadlineSeconds pod ，而Not Terminating 应用于那些没有指定该配置的 pod。

cat quota-scoped.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: besteffort-notterminating-pods
spec:
  scopes:
  - BestEffort
  - NotTerminating
  hard:
    pods: 4

这个配额允许最多创建4个属于 BestEffort QoS 等级，并没有设置 activedeadline pod 。
如果配额针对的是 NotBestEffort pod ，我们便可以指定 requests.cpu，requests memory，limits.cpu 和 limits .memory。

__EOF__

本文作者：何时&明月
本文链接：https://www.cnblogs.com/kiyalone/p/15957167.html
关于博主：当你发现自己的才华支撑不起野心时，就请安静下来学习吧！
版权声明：本博客所有文章除特别声明外，均采用 BY-NC-SA 许可协议。转载请注明出处！
声援博主：如果您觉得文章对您有帮助，可以点击文章右下角【推荐】一下。您的鼓励是博主的最大动力！