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