K8s核心资源对象-Pod(QoS与驱逐顺序)
K8s核心资源对象-Pod(QoS与驱逐顺序)
基于1.25
什么是QoS
Qos的三个选值:
Guaranteed:最严格的最不可怜面临驱逐,保证它们不会退出,直到超过它们的限制或没有可以从节点抢占的低优先级Pod
- 要求每一个Pod容器都要有limits和requests
- limits和requests必须相等
Burstable:Pod基于一些请求的下限保证,不需要特定的限制
不指定,使用None,允许Pod可用时候灵活增加资源
当Node资源压力导致Pod被驱逐,只有在所有的BestEffort类型的Pod被驱逐之后,Burstable才会被驱逐
要求至少有一个Pod有CPU requests和limits
BestEffort:如果节点面临资源压力,kubelete更愿意驱逐BestEffort的Pod
- 所有容器都没有limits和requests
QoS的计算
参与QoS:普通容器和Init容器,临时容器不参与。
流程如下:
把普通容器、Init容器追加到allContainers中
遍历Pod中所有参与计算的容器,获取requets,通过isSupportedQoSComputeResoure func过滤不参与QoS计算的资源。
- 只有cpu和memory,计算之后追加到ResourceList
limits的计算方法和requests相同。另外limits没有配置的资源添加到qosLimitFound这个map
len(requests)==0 &&len(limits)==0,所有容器没有配置requets和limits,属于BestEffort
当qosLimitsFound 没有包含 cpu 和 memory ,一定不是Cuaranteed类型,把isGuaranteed设置为false
如果是isGuaranteed 是true,即同时配置了requests和limits,并且不满足lim.Cmp(req)!=0。即同时配置了requests和limits,是Guaranteed
不属于BestEffort 和 Guarantee的情况 都属于Burstable
|
QoS影响kubelet驱逐Pod
下面的参数影响了Pod驱逐顺序:
- Pod资源使用量是否超过起请求量
- Pod的优先级
- Pod的相对于请求的资源使用情况
// rankMemoryPressure orders the input pods for eviction in response to memory pressure. |
QoS影响Linux的OOM Killer
当kubelet没来得及触发Pod驱逐,使得节点资源耗尽,将触发节点的Linux上的OOM killer。
根据一定算法,选择性终止一些进程,使得程序继续运行
终止的进程,计算每一个进程的点数,点数范围是0~1000
- 点数越高,进程越有可能被终止
- 进程的OOM点数等于oom_score+oom_score_adj;oom_score和进程消耗的内存有关,oom_score_adj是可以配置的,取值范围-1000~1000
根据QoS不同,kubelete的oom_socre_adj分数不一样
- Guaranteed:-997,基本上最后才会被OOM killer终止
- BestEffort:1000,最先被OOM killer 终止
oom_score_adj的定义初始值
|
oom_score_adj动态设置
如果是系统级别的Pod,设置为guaranteedOOMScoreAdj
如果Pod的QoS为Guaranteed,设置为guaranteedOOMScoreAdj
如果Pod的QoS为BestEffort,设置为besteffortOOMScoreAdj,值为1000,最先被OOM killer
如果Pod的QoS为Bursttable,根据其请求的系统资源比例,动态调整
- 如果容器请求10%的memory,OOM设置为900
- 如果超过百分之内存,OOM设置为1000
|