本文主要是介绍Kubernetes的Pod的资源配额，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
一.为什要进行资源配额
我们可以使用一些方法从多个维度保障了服务的可用性，比如调度到不同的机器和机房、配置可靠的健康检查等。但是上述措施都是基于应用级别去做的，如果我们的Kubernetes集群用来运行容器的节点有了故障，带来的影响是很大的，所以在保证应用本身的前提下，也要通过一些措施保障节点的可用性
节点故障大部分都是由于资源分配不合理、超额分配引起的，因此需要用某个技术手段保证节点的资源不会过大地超额分配，Kubernetes为我们提供了开箱即用的资源管理，可以通过ResourceQuota和LimitRange的配合防止节点资源超额分配。
二.ResourceQuota（资源配额）
首先看一下ResourceQuota（资源配额）的使用，资源配额是限制某个命名空间对资源使用的一个总量限制，比如内存，CPU，Pod数量等。
1.什么是资源配额
在生产环境中，可能会有多个Kubernetes集群，面向开发环境、测试环境、预生产环境和生产环境等。身为Kubernetes管理员，必然知道每个环境的规模有多大、可调度资源有多少，并且知道如何合理地为容器分配内存和CPU，所以一个管理员去管理整个Kubernetes集群时，很少会有资源分配超出集群可调度范围的情况。
但在实际使用时，Kubernetes集群并非只有一个管理员在使用，也并非只有管理员在使用。公司可能存在多个项目组，每个项目组都有属于自己的命名空间，每个项目组可以在其所在的命名空间创建资源而他们并不知道Kubernetes集群是多大规模，也不知道有多少可调度的资源，这样就很容易造成集群资源过量分配，引起集群不可用。在这种情况下，需要对每个项目组合理地分配资源用以避免超出集群的承能力，也可以减少废弃资源没有及时清理带来的资源浪费
为了解决上述问题，Kubernetes引入了ResourceQuota的概念，以方便Kubernetes管理员进行资源分配，比如给A项目组分配16核64GB的资源，并且最多只能部署20个Pod、30个Service等，这羊来对Kubernetes的各类资源进行限制
如果在一个命名空间内配置了ResourceQuota这个命名空间内的所有Pod都会受其影响
2.定义一个ResourceQuota
和其他资源配置方法一样，资源配额也可以通过yaml文件进行创建，比如定义一个比较常用的ResourceQuota如下：
apiVersion: v1
kind: ResourceQuota
metadata:name: resource-testlabels:app: resourcequota
spec:hard:pods: 50 #限制最多启动50个Podrequests.cpu: 0.5 #初始化要求的最低CPU数量requests.memory: 512Mi #初始化要求的最低内存数量limits.cpu: 5 #最高可用的CPU数量limits.memory: 16Gi #最高可用的内存数量configmaps: 20 #限制最多20个ConfigMaprequests.storage: 40Gi #请求 40 GiB 的存储空间，用于持久化存储persistentvolumeclaims: 20 #集群允许最多 20 个持久化卷声明replicationcontrollers: 20 #集群允许最多 20 个副本控制器secrets: 20 #集群允许最多 20 个机密services: 50 #集群允许最多 50 个服务（Services）。services.loadbalancers: "2" #集群允许最多 2 个负载均衡服务（LoadBalancers）services.nodeports: "10" #集群允许最多 10 个 NodePort 服务
3.ResourceQuota的使用
（1）创建命名空间
[root@k8s-master ~]# ku create ns quota-example
namespace/quota-example created
（2）编写ResourceQuota文件
该demo可以限制namespace的PVC不超过1个。
[root@k8s-master ~]# vim quota-objects.yaml apiVersion: v1
kind: ResourceQuota
metadata:name: object-quota-demo
spec:hard:persistentvolumeclaims: "1"
（3）创建该ResourceQuota
[root@k8s-master ~]# ku create -f quota-objects.yaml -n quota-example
resourcequota/object-quota-demo created
（4）查看创建的资源限制状态
[root@k8s-master ~]# ku get quota object-quota-demo -n quota-example
NAME AGE REQUEST LIMIT
object-quota-demo 69s persistentvolumeclaims: 0/1
[root@k8s-master ~]# ku get quota object-quota-demo -n quota-example -oyaml
apiVersion: v1
kind: ResourceQuota
metadata:creationTimestamp: "2024-08-30T03:18:00Z"name: object-quota-demonamespace: quota-exampleresourceVersion: "11752"uid: 2176d59b-b777-4745-8a0e-1fc08462986e
spec:hard:persistentvolumeclaims: "1"
status:hard:persistentvolumeclaims: "1"used:persistentvolumeclaims: "0"
备注：从STATUS字段的used看出，当前的资源显示的使用量，并且namespace只有在创建了ResourceQuota才会启用资源限制的配额 ，没有创建ResourceQuota的namespace不限制资源的使用。
（5）创建一个PVC
[root@k8s-master ~]# vim pvc.yaml apiVersion: v1
kind: PersistentVolumeClaim
metadata:name: pvc-quota-demo
spec:storageClassName: manualaccessModes:- ReadWriteOnceresources:requests:storage: 3Gi
root@k8s-master ~]# ku create -f pvc.yaml -n quota-example
persistentvolumeclaim/pvc-quota-demo created
（6）查看当前资源的使用情况
[root@k8s-master ~]# ku get quota object-quota-demo -n quota-example
NAME AGE REQUEST LIMIT
object-quota-demo 8m35s persistentvolumeclaims: 1/1 [root@k8s-master ~]# ku get quota object-quota-demo -n quota-example -oyaml
apiVersion: v1
kind: ResourceQuota
metadata:creationTimestamp: "2024-08-30T03:18:00Z"name: object-quota-demonamespace: quota-exampleresourceVersion: "12412"uid: 2176d59b-b777-4745-8a0e-1fc08462986e
spec:hard:persistentvolumeclaims: "1"
status:hard:persistentvolumeclaims: "1"used:persistentvolumeclaims: "1"
（7）在创建一个PVC
[root@k8s-master ~]# vim pvc2.yaml apiVersion: v1
kind: PersistentVolumeClaim
metadata:name: pvc-quota-demo2
spec:storageClassName: manualaccessModes:- ReadWriteOnceresources:requests:storage: 3Gi
[root@k8s-master ~]# ku create -f pvc2.yaml -n quota-example
Error from server (Forbidden): error when creating "pvc2.yaml": persistentvolumeclaims
"pvc-quota-demo2" is forbidden: exceeded quota: object-quota-demo, requested: persistentvolumeclaims=1,used: persistentvolumeclaims=1, limited: persistentvolumeclaims=1
因为ResourceQuota配置了此命名空间内只能创建一个PVC，在前面已经创建了一个，used的值已经变为：1；那一个PVC已经被使用过了，所以在创建PVC的时候会报上述错误。
（8）清理
[root@k8s-master ~]# ku delete -f pvc.yaml -n quota-example
persistentvolumeclaim "pvc-quota-demo" deleted
[root@k8s-master ~]# ku delete ns quota-example
namespace "quota-example" deleted三.LimiRange
1.为什么使用LimitRange
和ResourceQuota不同的是，LimiRange用来配置默认值，也就是一个Pod如果没有配置要用多少内存，CPU，LimiRange会创建Pod时添加一个默认值。
2.示例1：配置默认的Request和limits
可以通过LimiRange配置默认的Request和limits值，用来解决创建的资源没有配置或配置过小的Requests和Limits带来的问题，比如创建一个Requests.cpu默认为0.5（0.5为半个CPU，1个人CPU等于1000m），Requests.memory为256MB，Limits.cpu为1，Limits.memory为512MB的LimiRange：
（1）创建一个LimitRange
[root@k8s-master ~]# vim limitrange01.yaml apiVersion: v1
kind: LimitRange
metadata:name: cpu-mem-limit-range
spec:limits:- default:cpu: 1memory: 512MidefaultRequest:cpu: 0.5memory: 256Mitype: Container
---
apiVersion: v1
kind: Pod
metadata:name: default-cpu-demo
spec:containers:- name: default-cpu-demo-ctrimage: nginx:1.7.9
[root@k8s-master ~]# ku create -f limitrange01.yaml
limitrange/cpu-mem-limit-range created
pod/default-cpu-demo created
（2）查看pod信息
[root@k8s-master ~]# ku get pod default-cpu-demo -oyaml
··········containers:- image: nginx:1.7.9imagePullPolicy: IfNotPresentname: default-cpu-demo-ctrresources:limits:cpu: "1"memory: 512Mirequests:cpu: 500mmemory: 256Mi
··········（3）清除资源
[root@k8s-master ~]# ku delete -f limitrange01.yaml
limitrange "cpu-mem-limit-range" deleted
pod "default-cpu-demo" deleted
[root@k8s-master ~]# ku get pod
No resources found in default namespace.
3.示例2：配置requests和limits的范围
上述针对没有设置requests和limits字段的资源添加了默认值，但是并没有限制requests和limits的最大值和最小值，这样同样会给集群带来风险，所以在管理资源分配时，对request和limits的最大值和最小值也需要进行管控。
requests和limits的最大值和最小值的配置方式和默认值的配置差别不大。比如创建一个内存最大为1G，最小为500M和CPU最大为800m，最小为200m的LimiRange
（1）创建LimitRange的yaml文件
[root@k8s-master ~]# vim limitrange02.yaml apiVersion: v1
kind: LimitRange
metadata:name: cpu-min-max-demo-lr
spec:limits:- max:cpu: "800m"memory: 1Gimin:cpu: "200m"memory: "500Mi"type: Container
---
apiVersion: v1
kind: Pod
metadata:name: constraints-mem-demo-2
spec:containers:- name: constraints-mem-demo-2-ctrimage: nginx:1.7.9resources:limits:memory: "500Mi"requests:memory: "500Mi" （2）创建这个LimitRange和pod
[root@k8s-master ~]# ku create -f limitrange02.yaml
limitrange/cpu-min-max-demo-lr created
pod/constraints-mem-demo-2 created
（3）测试
[root@k8s-master ~]# ku get pod constraints-mem-demo-2 -oyaml
·······
containers:- image: nginx:1.7.9imagePullPolicy: IfNotPresentname: constraints-mem-demo-2-ctrresources:limits:cpu: 800mmemory: 500Mirequests:cpu: 800mmemory: 500Mi
·······将containers的内存参数memory调整为大于800。
[root@k8s-master ~]# ku create -f limitrange02.yaml
limitrange/cpu-min-max-demo-lr created
Error from server (Forbidden): error when creating "limitrange02.yaml": pods "constraints-mem-demo-2" is forbidden: maximum memory usage per Container is 1Gi, but limit is 1200Mi
（4）清除
4.示例3：限制申请存储空间的大小
LimitRange也可以对存储申请的大小进行限制，比如限制PVC申请空间的最小值为1GB，最大值为2GB（结合ResourceQuota可以同时限制最多存储使用量和最大PVC创建的数量）
（1） 编写限制请存储（PVC）的的配置文件
[root@k8s-master ~]# vim limitrange03.yaml apiVersion: v1
kind: LimitRange
metadata:name: storagelimits
spec:limits:- type: PersistentVolumeClaimmax:storage: 2Gimin:storage: 1Gi
（2）创建该LimitRange
[root@k8s-master ~]# ku create -f limitrange03.yaml
limitrange/storagelimits created
（3）创建测试用的pv yaml文件，并创建pv
[root@k8s-master ~]# vim hostpath-pv.yaml kind: PersistentVolume
apiVersion: v1
metadata:name: mypv-hostpathlabels:type: local
spec:storageClassName: pv-hostpathcapacity:storage: 10GiaccessModes:- ReadWriteOncehostPath:path: "/mnt/data"
[root@k8s-master ~]# ku create -f hostpath-pv.yaml
persistentvolume/mypv-hostpath created（4）创建测试用的请求存储PVC yaml文件
[root@k8s-master ~]# vim pvc-hostpath.yaml kind: PersistentVolumeClaim
apiVersion: v1
metadata:name: mypvc-hostpath
spec:storageClassName: pv-hostpathaccessModes:- ReadWriteOnceresources:requests:storage: 3Gi
创建pvc
[root@k8s-master ~]# ku create -f pvc-hostpath.yaml
Error from server (Forbidden): error when creating "pvc-hostpath.yaml": persistentvolumeclaims "mypvc-hostpath" is forbidden: maximum storage usage per PersistentVolumeClaim is 2Gi, but request is 3Gi
备注：可以看出pvc请求pv的存储空间为3Gi，但是LimitRange只让pvc请求1-2Gi的存储空间所以PVC请求失败。
四.服务质量（Qos）
虽然我们进行了资源限制，但是实际使用时依旧会造成节点资源不足，针对资源不足Kubernetes会通过重启或驱逐Pod释放资源，再重启时，难先会造成一些很重要的服务不可用。但实际情况可能是，如果重启或驱逐一些不重要的Pod可能会更好，而这种决策是通过QoS（Quality of service，服务质量）决定的，所以在生产环境中，QoS是一个非常重要的环节。
1. 什么是服务质量
服务质量（QoS）是指当宿主机的资源不足时，按照级别驱逐或杀死Pod，以确保重要的服务资源（高级别）能够正常运行。
2.三种级别的服务质量
- Guaranteed：最高服务质量，当宿主机内存或cpu不够时，会先杀死BestEffort和Burstable的Pod，如果内存或cpu还是不够，才会杀死Qos为Guaranteed的pod，该级别pod的资源占用量一般比较明确，即request字段的cpu和memory与limits字段的cpu和memory配置的一致。
- Burstable：服务质量低于Guaranteed，当宿主机内存不够时，会先杀死QoS为BestEffort的Pod，如果内存还是不够，就会杀死QoS级别为Burstable的Pod，用未保证QoS质量为Guaranteed的Pod，该级别的Pod一般知道最小资源使用量，但是当机器资源充足时，还是想尽可能使用更多的资源，即1imits字段的cpu和memory大于requests字段的cpu和memory的配置。
- BestEffort：尽力而为，当宿主机内存不够时，首先杀死的就是该QoS的Pod，用以保证Burstable和Guaranteed级别的Pod正常运行。
实现不同级别的服务质量是根据requests和limits的配置决定的在宿主机资源不够时会先杀死服务质量为BestEffort的Pod，然后杀死服务质量为Burstable的Pod，最后杀死服务质量为Guaranteed的Pod。所以在生产环境中比较重要的应用最好设置为Guaranteed，当然如果集群资源足够使用，可以都设置为Guaranteed.。
3.三种Qos服务质量的实现
（1）创建一个用于测试的Namespace命名空间
[root@k8s-master ~]# ku create ns qos-example
namespace/qos-example created
（2）实现Qos为Guaranteed的Pod
满足条件：Pod中每个容器必须指定的limits.memory和request.memory必须相等；且limits.cpu和request.cpu也必须相等。
创建此类pod的yaml文件
[root@k8s-master ~]# vim qos-pod.yaml apiVersion: v1
kind: Pod
metadata:name: qos-demonamespace: qos-example
spec:containers:- name: qos-demo-ctrimage: nginx:1.7.9resources:limits:memory: "200Mi"cpu: "700m"requests:memory: "200Mi"cpu: "700m"
创建处来并查看结果
[root@k8s-master ~]# ku create -f qos-pod.yaml -n qos-example
pod/qos-demo created[root@k8s-master ~]# ku get pod qos-demo -n qos-example -oyaml
·········podIPs:- ip: 10.244.140.72qosClass: GuaranteedstartTime: "2024-08-30T08:29:35Z"
···（2）实现Qos为Burstable的Pod
满足条件：
- pod不符合Guaranteed的配置要求
- pod中至少有一个容器配置了request.cpu或者request.memory
编写服务质量为Burstable的pod的yaml文件
[root@k8s-master ~]# vim qos-pod-2.yaml apiVersion: v1
kind: Pod
metadata:name: qos-demo-2namespace: qos-example
spec:containers:- name: qos-demo-2-ctrimage: nginx:1.7.9resources:limits:memory: "200Mi"requests:memory: "100Mi"
创建并查看测试结果
[root@k8s-master ~]# ku create -f qos-pod-2.yaml -n qos-example
pod/qos-demo-2 created[root@k8s-master ~]# ku get pod qos-demo-2 -n qos-example -oyaml
········
podIP: 10.244.196.136podIPs:- ip: 10.244.196.136qosClass: BurstablestartTime: "2024-08-30T08:35:57Z"
（3）实现Qos为BestEffort的Pod
条件：Pod中所有容器都没有设置requests和limits字段即可。
创建服务质量为BestEffort的Pod的yaml文件
[root@k8s-master ~]# vim qos-pod-3.yaml apiVersion: v1
kind: Pod
metadata:name: qos-demo-3namespace: qos-example
spec:containers:- name: qos-demo-3-ctrimage: nginx:1.7.9
创建该Pod，并查看服务质量
[root@k8s-master ~]# ku create -f qos-pod-3.yaml -n qos-example
pod/qos-demo-3 created[root@k8s-master ~]# ku get pod qos-demo-3 -n qos-example -oyaml
··········
podIP: 10.244.196.137podIPs:- ip: 10.244.196.137qosClass: BestEffortstartTime: "2024-08-30T08:39:20Z"
4.总结
提升服务可用性只从应用程序级别考虑是远远不够的，也需要考虑服务器的稳定性。在使用Kubernetes部署程序时，很容易造成资源的过量分配，作为Kubernetes管理员，必须要去考虑服务器的可用性，防止服务器岩机带来的雪。
通常情况下，依赖的底层中间件的QoS会配置为Guaranteed，其他服务可能并不需要那么高的QoS。在实际使用时。最有可能超额分配的是内存，而CPU通常使用率不高，只有在高频工作时，CPU才会处于忙碌状态。所以在设置resources参数时，内存的request需要按需配置，比如一个程序的运行内存最少为2GB，那么内存的request就要设置为2GB，而不能低于2GB。对于CPU，Limit数很重要，防止Pod的CPU过高，从而引起宿主机的问题
所以在生产环境部署一个程序时，需要从应用的健康检查、平滑退出、亲和力、QoS和ResourceQuota等多个维度去考虑应用的健壮性，这些都是不可省略的配置
这篇关于Kubernetes的Pod的资源配额的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
