Kubernetes -- Pod的Qos分析

requests和limits

pod可以配置每个container的requests以标识资源申请额，配置limits以限制资源使用上限。

kubernetes根据requests，调度pod运行在哪个节点上。

kubernetes根据limits，限制pod可以使用cpu/memory资源:

• 当容器使用的cpu达到limits时，进程不会分配到更多的cpu；
• 当容器使用的memory达到limits时，容器会被OOMKilled，尝试重启；

apiVersion: v1
Kind: Pod
metadata:
  name: pod1
spec:
  containers:
  - image: nginx
    name: main
    resources:
      requests:
        cpu: 200m
        memory: 10Mi
      limits:
        cpu: 500m
        memory: 100Mi

为什么需要pod Qos?

requests与limits不同，单个节点上，所有limits的总和运行超过节点资源总量的100%，也就是说，limits可以超卖：

如果节点资源使用量超过100%，一些容器会被杀掉，比如podA使用了节点内存的90%，podB突然需要节点20%的内存，导致节点无法提供更多的内存，此时该杀掉哪个pod以满足podB的内存请求？

kubernetes通过pod的Qos级别，决定当资源不足时，优先杀掉哪些容器：

• BestEffort: 优先级最低(最先被Kill)
• Burstable:
• Guaranteed: 优先级最高(最后被Kill)

当遇到内存不足，BestEffort的Pod有多个，如何确定该kill哪个：

• 根据进程的OOM分数来选择，分数越高，优先被杀掉；
• OOM分数：(实际内存使用量 / request.memory )的值越大，OOM分数越高；

如何确定pod Qos？

方法一：kubectl describe pod查询

# kubectl describe pod -n monitoring prometheus-k8s-0

Name:         prometheus-k8s-0
Namespace:    monitoring
......
QoS Class:       Burstable
......

方法二：按下面的规则(推荐)

BestEffort:

• 所有的容器都没有分配requests和limits；

Guaranteed:

• 所有的容器都分配了requests和limits;

Burstable:

• 其它不属于BestEffort和Guaranteed的pod;

方法三：先判断container的Qos，再判断pod的qos

container的Qos判断方法：

pod的Qos判断方法：

参考：

1. kubernetes in action