资源配额管理（Resource Quotas）

如果一个Kubernetes集群被多个用户或者多个团队共享，就需要考虑资源公平使用的问题，因为某个用户可能会使用超过基于公平原则分配给其的资源量。

Resource Quotas就是解决这个问题的工具。通过ResourceQuota对象，我们可以定义资源配额，这个资源配额可以为每个命名空间都提供一个总体的资源使用的限制：它可以限制命名空间中某种类型的对象的总数目上限，也可以设置命名空间中Pod可以使用的计算资源的总上限。

典型的资源配额使用方式如下。

◎　不同的团队工作在不同的命名空间下，目前这是非约束性的，在未来的版本中可能会通过ACL（Access Control List，访问控制列表）来实现强制性约束。
◎　集群管理员为集群中的每个命名空间都创建一个或者多个资源配额项。
◎　当用户在命名空间中使用资源（创建Pod或者Service等）时，Kubernetes的配额系统会统计、监控和检查资源用量，以确保使用的资源用量没有超过资源配额的配置。
◎　如果在创建或者更新应用时资源使用超过了某项资源配额的限制，那么创建或者更新的请求会报错（HTTP 403 Forbidden），并给出详细的出错原因说明。
◎　如果命名空间中的计算资源（CPU和内存）的资源配额启用，那么用户必须为相应的资源类型设置Requests或Limits；否则配额系统可能会直接拒绝Pod的创建。这里可以使用LimitRange机制来为没有配置资源的Pod提供默认资源配置。

下面的例子展示了一个非常适合使用资源配额来做资源控制管理的场景。
◎　集群共有32GB内存和16 CPU，两个小组。A小组使用20GB内存和10 CPU，B小组使用10GB内存和2 CPU，剩下的2GB内存和2 CPU作为预留。
◎　在名为testing的命名空间中，限制使用1 CPU和1GB内存；在名为production的命名空间中，资源使用不受限制。

在使用资源配额时，需要注意以下两点。
◎　如果集群中总的可用资源小于各命名空间中资源配额的总和，那么可能会导致资源竞争。资源竞争时，Kubernetes系统会遵循先到先得的原则。
◎　不管是资源竞争还是配额的修改，都不会影响已经创建的资源使用对象。

1.在Master中开启资源配额选型

资源配额可以通过在kube-apiserver的--admission-control参数值中添加ResourceQuota参数进行开启。如果在某个命名空间的定义中存在ResourceQuota，那么对于该命名空间而言，资源配额就是开启的。一个命名空间可以有多个ResourceQuota配置项。

1）计算资源配额（Compute Resource Quota）

资源配额可以限制一个命名空间中所有Pod的计算资源的总和。目前支持的计算资源类型如下表：

资源名称	说         明
Cpu	所有非终止状态的Pod，CPU Requests的总和不能超过该值
limits.cpu	所有非终止状态的Pod， CPU Limits的总和不能超过该值
limits.memory	所有非终止状态的Pod，内存 Limits的总和不能超过该值
Memory	所有非终止状态的Pod， 内存 Requests的总和不能超过该值
requests.cpu	所有非终止状态的Pod，CPU Requests的总和不能超过该值
requests.memory	所有非终止状态的Pod， 内存Requests的总和不能超过该值

2）存储资源配额（Volume Count Quota）

可以在给定的命名空间中限制所使用的存储资源（Storage Resources）的总量，目前支持的存储资源名称如下表;

资源名称	说明
requests.storage	所有PVC，存储请求总量不能超过此值
PersistentVolumeclaims	在该命名空间中能存在的持久卷的总数上限
.storageclass.storage.k8s.io/requests.storage	和该存储类关联的所有PVC，存储请求总和不能超过此值
.storageclass.storage.k8s.io/persistentvolumeclaims	和该存储类关联的所有PVC的总和

3） 对象数量配额（Object Count Quota）

指定类型的对象数量可以被限制。下表列出了ResourceQuota支持限制的对象类型。

资源名称	说明
Configmaps	在该命名空间中能存在的ConfigMap的总数上限
Pods	在该命名空间中能存在的非终止状态Pod的总数上限，Pod终止状态等价于Pod的 status.phase in(Failed, Succeeded) = true
Replicationcontrollers	在该命名空间中能存在的RC的总数上限
Resourcequtas	在该命名空间中能存在的资源配额项的总数上限
Services	在该命名空间中能存在的Service的总数上限
service.loadbalancers	在该命名空间中能存在的负载均衡的总数上限
services.nodeports	在该命名空间中能存在的NodePort的总数上限
Secrets	在该命名空间中能存在的Secret的总数上限

例如，我们可以通过资源配额来限制在命名空间中能创建的Pod的最大数量。这种设置可以防止某些用户大量创建Pod而迅速耗尽整个集群的Pod IP和计算资源。

2.配额的作用域（Quota Scopes）

每项资源配额都可以单独配置一组作用域，配置了作用域的资源配额只会对符合其作用域的资源使用情况进行计量和限制，作用域范围内超过了资源配额的请求都会报验证错误。下表列出了ResourceQuota的4种作用域。

作用域	说明
Termination	匹配所有spec.activeDeadlineSeconds 不小于0的Pod
NotTermination	匹配所有spec.activeDeadlineSeconds是nil的Pod
BestEffort	匹配所有QoS是 BestEffort的Pod
NotBestEffort	匹配所有QoS不是BestEffort的Pod

其中，BestEffort作用域可以限定资源配额来追踪pods资源的使用，Terminating、NotTerminating和NotBestEffort这三种作用域可以限定资源配额来追踪以下资源的使用。

◎　cpu
◎　limits.cpu
◎　limits.memory
◎　memory
◎　pods
◎　requests.cpu
◎　requests.m

3 在资源配额（ResourceQuota）中设置Requests和Limits

资源配额也可以设置Requests和Limits。

如果在资源配额中指定了requests.cpu或requests.memory，那么它会强制要求每个容器都配置自己的CPU Requests或CPU Limits（可使用LimitRange提供的默认值）。

同理，如果在资源配额中指定了limits.cpu或limits.memory，那么它也会强制要求每个容器都配置自己的内存Requests或内存Limits（可使用LimitRange提供的默认值）。

4 资源配额定义

下面通过几个例子对资源配额进行设置和应用。

与LimitRange相似，ResourceQuota也被设置在Namespace中。创建名为myspace的Namespace：

kubectl create namespace myspace

创建ResourceQuota配置文件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

kubectl create -f compute-resources.yaml --namespace=myspace

创建另一个名为object-counts.yaml的文件，用于设置对象数量的配额：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: object-counts
spec:
  hard: 
    configmaps: "10"
    persistentvolumeclaims: "4"
    replicationcontrollers: "20"
    sercets: "10"
    services: "10"
    services.loadbalancers: "2" 

创建该ResourceQuota:

kubectl create -f object-counts.yaml --namespace=myspace

查看各ResourceQuota的详细信息：

kubectl describe quota compute-resources --namespace=myspace

资源配额与集群资源总量的关系

资源配额与集群资源总量是完全独立的。资源配额是通过绝对的单位来配置的，这也就意味着如果在集群中新添加了节点，那么资源配额不会自动更新，而该资源配额所对应的命名空间中的对象也不能自动增加资源上限。

在某些情况下，我们可能希望资源配额支持更复杂的策略，如下所述。

◎　对于不同的租户，按照比例划分整个集群的资源。
◎　允许每个租户都能按照需要来提高资源用量，但是有一个较宽容的限制，以防止意外的资源耗尽情况发生。
◎　探测某个命名空间的需求，添加物理节点并扩大资源配额值。

这些策略可以通过将资源配额作为一个控制模块、手动编写一个控制器来监控资源使用情况，并调整命名空间上的资源配额来实现。

资源配额将整个集群中的资源总量做了一个静态划分，但它并没有对集群中的节点做任何限制：不同命名空间中的Pod仍然可以运行在同一个节点上。

 

小结：

         本节内容到此结束，谢谢大家的浏览。

         资源管理部分涉及的东西较多，更新的章节也会比较多，希望大家谅解。

         而且最近在公司经常加班，实属扛不住。