K8S入门篇-资源配额管理

作者：@skyflask
转载本文请注明出处：https://www.cnblogs.com/skyflask/p/16836553.html

---

目录

一、资源配额(namespace)
1.1 为什么要有资源配额
1.2 资源配额案例
二、生产必备LimitRange(pod)
2.1 为什么要有limitrange
2.2 默认的limits和requests
2.3 limits和requests的范围
三、服务质量QoS
3.1 Guaranteed的pod实现
3.2 Burstable的pod实现
3.3 BestEffort的pod实现

一、资源配额(namespace)

1.1 为什么要有资源配额

当多个用户或团队共享具有固定节点数目的集群时，人们会担心有人使用超过其基于公平原则所分配到的资源量。

资源配额是帮助管理员解决这一问题的工具。

资源配额，通过 ResourceQuota 对象来定义，对每个命名空间的资源消耗总量提供限制。 它可以限制命名空间中某种类型的对象的总数目上限，也可以限制命名空间中的 Pod 可以使用的计算资源的总上限。

资源配额限制的资源：

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

apiVersion: v1 kind: ResourceQuota metadata:   name: resource-test   labels:     app: resourcequota spec:   hard:     pods: 50     requests.cpu: 0.5     requests.memory: 512Mi     limits.cpu: 5     limits.memory: 16Gi     configmaps: 20     requests.storage: 40Gi     persistentvolumeclaims: 20     replicationcontrollers: 20     secrets: 20     services: 50     services.loadbalancers: "2"     services.nodeports: "10"

　　

1.2 资源配额案例

创建一个资源配额，对rq-test这个namespace。

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

cat resource-quota.yaml apiVersion: v1 kind: ResourceQuota metadata:   name: resource-test   labels:     app: resourcequota spec:   hard:     pods: 2     requests.cpu: 0.5     requests.memory: 512Mi     limits.cpu: 5     limits.memory: 16Gi     configmaps: 20     requests.storage: 40Gi     persistentvolumeclaims: 20     replicationcontrollers: 20     secrets: 20     services: 50     services.loadbalancers: "2"     services.nodeports: "10"

　

创建

?

1	kubectl apply -f resource-quota.yaml -n rq-test

　　

创建一个deployment

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

cat nginx-dp.yaml apiVersion: apps/v1 kind: Deployment metadata:   labels:     app: rq-test-dp   name: nginx   namespace: rq-test spec:   replicas: 3 #副本数   revisionHistoryLimit: 10 # 历史记录保留的个数   selector:     matchLabels:       app: nginx   template:     metadata:       labels:         app: nginx     spec:       containers:       - image: nginx:1.15.2         imagePullPolicy: IfNotPresent         name: nginx         resources:           limits:             memory: "80Mi"             cpu: "80m"           requests:             memory: "60Mi"             cpu: "40m"

　　注意：pod需要创建3个，而我们的资源配额限制的是2个。

创建  

?

1	kubectl apply -f nginx-dp.yaml

　　

查看结果

 

 

二、生产必备LimitRange(pod)

2.1 为什么要有limitrange

默认情况下， Kubernetes 集群上的容器运行使用的计算资源没有限制。 使用 Kubernetes 资源配额， 管理员（也称为集群操作者）可以在一个指定的命名空间内限制集群资源的使用与创建。 在命名空间中，一个 Pod 最多能够使用命名空间的资源配额所定义的 CPU 和内存用量。 作为集群操作者或命名空间级的管理员，你可能也会担心如何确保一个 Pod 不会垄断命名空间内所有可用的资源。

一个 LimitRange（限制范围） 对象提供的限制能够做到：

• 在一个命名空间中实施对每个 Pod 或 Container 最小和最大的资源使用量的限制。
• 在一个命名空间中实施对每个 PersistentVolumeClaim 能申请的最小和最大的存储空间大小的限制。
• 在一个命名空间中实施对一种资源的申请值和限制值的比值的控制。
• 设置一个命名空间中对计算资源的默认申请/限制值，并且自动的在运行时注入到多个 Container 中。

2.2 默认的limits和requests

创建limitrange

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-mem-limit-range
spec:
  limits:
  - default:  #limits
      cpu: 1
      memory: 512Mi
    defaultRequest: #requests
      cpu: 0.5
      memory: 256Mi
    type: Container

 

?

1	kubectl apply -f limitrange.yaml  -n rq-test

　　

创建deploy测试

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

apiVersion: apps/v1 kind: Deployment metadata:   labels:     app: rq-test-dp   name: nginx   namespace: rq-test spec:   replicas: 3 #副本数   revisionHistoryLimit: 10 # 历史记录保留的个数   selector:     matchLabels:       app: nginx   template:     metadata:       labels:         app: nginx     spec:       containers:       - image: nginx:1.15.2         imagePullPolicy: IfNotPresent         name: nginx         resources:           limits:             memory: "200Mi"             cpu: "400m"           requests: #至少400mcore，200M内存             memory: "200Mi"             cpu: "400m"

　

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

[root@k8s-master01 ~/k8s]# kubectl describe quota -n rq-test Name:                   resource-test Namespace:              rq-test Resource                Used   Hard --------                ----   ---- configmaps              1      20 limits.cpu              400m   5 limits.memory           200Mi  16Gi persistentvolumeclaims  0      20 pods                    1      3 replicationcontrollers  0      20 requests.cpu            400m   500m requests.memory         200Mi  512Mi requests.storage        0      40Gi secrets                 1      20 services                0      50 services.loadbalancers  0      2 services.nodeports      0      10

　　

查看结果：

发现只能创建1个pod，limitrange的cpu是500m，我们创建pod时一个使用400m，所以最多生成1个pod，其他因为资源不足而创建失败了。

 

2.3 limits和requests的范围

 

 

除了默认的limits和requests以外，我们还可以控制limits和requests的最大值和最小值

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

apiVersion: v1 kind: LimitRange metadata:   name: cpu-mem-limit-range spec:   limits:   - max:         #限制最大值的cpu是800m，内存1G       cpu: "800m"       memory: "1Gi"     min:         #限制最小值的cpu100m，内存99M       cpu: "200m"       memory: "99Mi"     default:       #默认limits的cpu200m，内存500M       cpu: "200m"       memory: "500Mi"     defaultRequest: #默认requests的cpu 100m，内存100M       cpu: "200m"       memory: "200Mi"     type: Container

　　如果deploy或pod中没有定义limits和requets的话，则会使用limitrange的limits和requests。否则会使用自己定义的值。

 

2.4 限制存储使用率

场景：限制存储使用量

集群管理员代表用户群操作集群，该管理员希望控制单个名字空间可以消耗多少存储空间以控制成本。该管理员想要限制：

1. 名字空间中持久卷申领（persistent volume claims）的数量
2. 每个申领（claim）可以请求的存储量
3. 名字空间可以具有的累计存储量

使用quota限制请求的pvc数量和大小：

?

1 2 3 4 5 6 7 8

apiVersion: v1 kind: ResourceQuota metadata:   name: storagequota spec:   hard:     persistentvolumeclaims: "5"     requests.storage: "5Gi"

　　

使用limitrange限制申请PVC最小为1G，最大为2G：

?

1 2 3 4 5 6 7 8 9 10 11

apiVersion: v1 kind: LimitRange metadata:   name: storagelimits spec:   limits:   - type: PersistentVolumeClaim     max:       storage: 2Gi     min:       storage: 1Gi

　　

创建一个pvc，requests为8G，我们配置的quota为5G：

 

 

三、服务质量QoS

 

 

 

3.1 Guaranteed的pod实现

 

 

 

3.2 Burstable的pod实现

 

 

 

 

3.3 BestEffort的pod实现