关于kubernetes: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