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可以超卖:
Kubernetes -- Pod的Qos分析_第1张图片

如果节点资源使用量超过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判断方法:
Kubernetes -- Pod的Qos分析_第2张图片

pod的Qos判断方法:
Kubernetes -- Pod的Qos分析_第3张图片

参考:

  1. kubernetes in action

你可能感兴趣的:(kubernetes)