Kubernetes 源码 (16) 计算资源管理 2

Submitted by Lizhe on Fri, 07/17/2020 - 02:18

上一节中我们出现了 OOM kill ,pod 的状态会变成 

CrashLoopBackOff 

CrashLoopBackOff 状态表示 Kubelet 还没有放弃,它意味着在崩溃之后Kubelet会增加下次重启的间隔时间

间隔时间会按照 10秒,20秒,40秒,80秒,160秒,最终收敛于 300 秒

一旦间隔时间到达 300 秒,Kubelet 将会以固定的 300 秒 为间隔时间对容器进行无限重启

 


 

在容器中看到的始终是节点的整体内存,而不是容器被限制使用的内存

在容器中看到的始终是节点的整体cpu内核,而不是容器被限制使用的内核,而且容器的进程会随机在node的内核上调用


 

下面的内容也很重要

Pod QoS 等级

Qos 等级直接影响当资源耗尽时,哪些容器会被优先杀死的问题

需要特别注意的是,QoS 等级是作用于 Pod 的, 但是决定 QoS等级的是 运行在 Pod 上的所有 容器,并且被杀死的是容器,而不是 pod,运行在同一个pod上的容器,拥有相同的QoS

BestEffort ( 最低优先级,第一批被杀死 )

Burstable

Guaranteed ( 最高优先级 )

你无法通过配置一个字段来直接设置上面这3个优先级,它是通过pod的 requests 和 limits 来配置的。

 

BestEffort:

这是最低的优先级,会分配给那些 没有为任何容器设置 requests 和 limits 的pod。
这个等级的容器没有任何资源保证,在最坏情况下它们分不到任何 cpu 资源,同时需要为其他pod 释放内存时,这些容器也会被第一批被杀死。
但是因为BestEffort pod没有配置任何内存 limits , 当有足够的内存可用时,这些容器可以使用任意多的内存。

Guaranteed:

所有容器的 Request 和 limits 都相等的 Pod 会被分配为 Guaranteed

cpu 和 内存 都要设置 requests 和 limits
每个容器都要设置资源量
每个容器的 每种资源的 requests 和 limits 都必需相等
 

 

注意:这种情况下容器可以只设置 Limits 值即可,引入在只设置 Limits 不设置 Requests 情况下,Requests 值默认等于 Limits 的值。

Burstable:

Burstable 介于BestEffort 和 Guaranteed 之间,其他所有的 pod 都属于这个等级。包括 容器的 requests 和 limits 不相同的单容器 pod,只有一个容器定义了requests 但是没定义 limits 的pod,以及一个容器的requests 和 limits 相等,另一个不相等的多容器 pod。

Burstable pod 可以获得它们所申请的等额资源,并可以使用不超过limits的额外资源

 

再重申一遍

QoS 等级是作用于 Pod 的,QoS 是pod上的一个属性, 但是决定 QoS等级的是 运行在 Pod 上的所有 容器,并且被杀死的是容器,而不是 pod,运行在同一个pod上的容器,拥有相同的QoS

那么当需要杀死一个容器来释放资源时,到底会先杀掉那个容器呢?并不是按照3个等级来区分那么简单

如果两个容器的 QoS 相同 ( 两个容器可能在一个pod上,也可能在不同的pod上,但是它们的 QoS 相同 ) 要先杀死哪一个呢?

如何处理相同 QoS 等级的容器

每个运行中的进程都有一个称为 OOM 分数的值。

系统通过比较进程的 OOM 分数值来决定要杀掉哪个进程。当需要释放内存时,分数最高的进程将被杀死。

OOM 分数由两个参数计算得出

1. 进程已经消耗内存占可用内存的百分比

2. 基于pod QoS 等级 和 容器内存申请量 固定的OOM 分数调节因子。

对于两个属于Burstable 等级的 单容器 pod,系统会杀掉 内存实际使用量占内存申请量 比例更高的 pod