k8s-----25、资源调度-ResourceQuota资源配额、资源限制limitrange、服务质量QoS

1、ResourceQuota资源配额

1.0 作用

命名空间资源配额。防止公司内部人员对资源的不合理利用。

1.1、为什么需要资源配额

1、作为k8s集群的管理员，知道集群的规模，会合理规划资源，但是使用侧不知道，会导致很多不合理的使用场景，造成浪费。

2、大量资源废弃后，没有合理清理，存在集群被打爆的风险。

3、加了资源配额限制之后，可以合理配置资源，并让使用方做到定期清理无用资源。

1.2、配置参数

yaml 复制代码

#创建resourcequota
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"

#参数解释
➢ pods:限制最多启动Pod的个数
➢ requests.cpu:限制pod最低CPU请求数
➢ requests.memory:限制pod最低内存的请求数 
➢ limits.cpu:限制最高CPU的limit上限
➢ limits.memory:限制最高内存的limit上限

2、LimitRange资源限制

2.1 作用

1、防止出现总资源一定的情况下，大家不指定pod的所需资源，那么创建的Pod都没有配置resources，会发现最终统计的资源使用为0，那么就可以无限创建pod。

2、可以无限制的对pod的资源进行扩展，比如可能直接创建的就是16C16G，导致无资源可用。

2.2 限制

1、deploy 已经创建的不会影响，如果pod重建过后，会将limitrange的配置刷新到新的pod里。

2、通过edit编辑了pod的resource参数，那么是不会被limitrange更改掉。

3、创建的时候需要指定对应的命名空间。

2.3 使用

limit可以同时配置，只有type不一致的时候，需要新开一行编写。

2.3.1 默认limitrange配置

yaml 复制代码

# 默认配置是为了控制资源利用情况，针对不同类型进行了默认的资源使用配置
# default:默认limits配置
# defaultRequest:默认requests配置
apiVersion: v1 
kind: LimitRange 
metadata:
  name: cpu-mem-limit-range 
spec:
  limits:
  - default:
      cpu: 1
      memory: 512Mi 
    defaultRequest:
      cpu: 0.5
      memory: 256Mi 
    type: Container  #类型是容器

2.3.2 requests和limits的范围

yaml 复制代码

#最大最小的配置是为了方式资源无限制的配置，导致资源浪费与资源打满
# max:内存CPU的最大配置 
# min:内存CPU的最小配置
apiVersion: v1 
kind: LimitRange 
metadata:
  name: cpu-min-max-demo-lr 
spec:
  limits: 
  - max:
      cpu: "800m"
      memory: 1Gi 
    min:
      cpu: "200m"
      memory: 500Mi 
    type: Container

2.3.3 限制申请存储空间

yaml 复制代码

# max:最大PVC的空间 
# min:最小PVC的空间
apiVersion: v1 
kind: LimitRange 
metadata:
  name: storagelimits 
spec:
  limits:
  - type: PersistentVolumeClaim #类型是pvc
    max: 
      storage: 2Gi
    min:
      storage: 1Gi

2.3.4 整体配置

yaml 复制代码

apiVersion: v1 
kind: LimitRange 
metadata:
  name: cpu-min-max-demo-lr 
spec:
  limits: 
  - default:
      cpu: 1
      memory: 512Mi 
    defaultRequest:
      cpu: 0.5
      memory: 256Mi 
    max:
      cpu: "800m"
      memory: 1Gi 
    min:
      cpu: "200m"
      memory: 500Mi 
    type: Container #类型容器
  - type: PersistentVolumeClaim #类型是pvc
    max: 
      storage: 2Gi
    min:
      storage: 1Gi

3、服务质量QoS

3.1 QoS级别

➢ Guaranteed:最高服务质量，当宿主机内存不够时，会先kill掉QoS为BestEffort和 Burstable的Pod，如果内存还是不够，才会kill掉QoS为Guaranteed，该级别Pod的资源占用量一般比较明确，即requests的cpu和memory和limits的cpu和memory配置的一致。

➢ Burstable: 服务质量低于Guaranteed，当宿主机内存不够时，会先kill掉QoS为 BestEffort的Pod，如果内存还是不够之后就会kill掉QoS级别为Burstable的Pod，用来保证QoS质量为Guaranteed的Pod，该级别Pod一般知道最小资源使用量，但是当机器资源充足时，还是想尽可能的使用更多的资源，即limits字段的cpu和memory大于 requests的cpu和memory的配置。

➢ BestEffort:尽力而为，当宿主机内存不够时，首先kill的就是该QoS的Pod，用以保证 Burstable和Guaranteed级别的Pod正常运行。这个类型的QoS没有配置resources。

3.2 不同级别的配置

3.2.1 QoS为Guaranteed的Pod

yaml 复制代码

# 1 Pod中的每个容器必须指定limits.memory和requests.memory， 并且两者需要相等;
# 2 Pod中的每个容器必须指定limits.cpu和limits.memory，并且两 者需要相等。

apiVersion: v1 
kind: Pod 
metadata:
  name: qos-demo
  namespace: qos-example 
spec:
  containers:
  - name: qos-demo-ctr
    image: nginx
    resources: 
      limits:
        memory: "200Mi"
        cpu: "700m" 
      requests:
        memory: "200Mi" 
        cpu: "700m"

3.2.2 QoS为Burstable的Pod

yaml 复制代码

# 1 Pod不符合Guaranteed的配置要求;
# 2 Pod中至少有一个容器配置了requests.cpu或requests.memory。
apiVersion: v1 
kind: Pod 
metadata:
  name: qos-demo
  namespace: qos-example 
spec:
  containers:
  - name: qos-demo-ctr
    image: nginx
    resources: 
      limits:
        memory: "200Mi"
      requests:
        memory: "100Mi"

3.2.3 QoS为BestEffort的Pod

yaml 复制代码

# 1 不设置resources参数
apiVersion: v1 
kind: Pod 
metadata:
  name: qos-demo
  namespace: qos-example 
spec:
  containers:
  - name: qos-demo-ctr
    image: nginx