Kubernetes 允许节点的 Pod 对象过载使用资源,这意味着节点无法同时满足绑定其上的所有 Pod 对象以资源满载的方式运行。因而在内存资源紧缺的情况下,应该以何种次序终止哪些 Pod 对象就变成了问题。
事实上,Kubernetes 无法自行对此做出决策,它需要借助于 Pod 对象的服务质量和优先级等完成判定。根据 Pod 对象的 requests
和 limits
属性,Kubernetes 把 Pod 对象归类到 BestEffort、Burstable 和 Guaranteed 这 3 个服务质量类别(Quality of Service,
QoS)下。
- Guaranteed: Pod 对象为其每个容器都设置了 CPU 资源需求和资源限制,且二者具有相同值;同时为每个容器都设置了内存需求和内存限制,且二者具有相同值。这类 Pod 对象具有最高级别服务质量。
- Burstable:至少有一个容器设置了 CPU 或内存资源的
requests
属性,但不满足 Guaranteed 类别的设定要求,这类 Pod 对象具有中等级别服务质量。 - BestEffort:不为任何一个容器设置
requests
或limits
属性,这类 Pod 对象可获得的服务质量为最低级别。
一旦内存资源紧缺,BestEffort 类别的容器将首当其冲地被终止,因为系统不为其提供任何级别的资源保证,但换来的好处是,它们能够做到尽可能多地占用资源。若此时系统上已然不存任何 BestEffort 类别的容器,则接下来将轮到 Burstable 类别的 Pod 被终止。
Guaranteed 类别的容器拥有最高优先级,它们不会被杀死,除非其内存资源需求超限,或者 OOM 时没有其他更低优先级的 Pod 对象存在。
每个运行状态的容器都有其 OOM 评分,评分越高越优先被杀死。OOM 评分主要根据两个维度进行计算:由服务质量类别继承而来的默认分值,以及容器的可用内存资源比例,而同等类别的 Pod 对象的默认分值相同。
因此,同等级别优先级的 Pod 资源在 OOM 时,与自身的 requests
属性相比,其内存占用比例最大的 Pod 对象将先被杀死。
需要特别说明的是,OOM 是内存耗尽时的处理机制,与可压缩型资源 CPU 无关,因此 CPU 资源的需求无法得到保证时,Pod 对象仅仅是暂时获取不到相应的资源来运行而已。
评论区