本站文章除注明转载/出处外,均为本站原创或翻译,转载前请务必署名原文链接~~~

Pod 服务质量类别

微信搜索 zze_coding 或扫描 👉 二维码关注我的微信公众号获取更多资源推送:


Kubernetes 允许节点的 Pod 对象过载使用资源,这意味着节点无法同时满足绑定其上的所有 Pod 对象以资源满载的方式运行。因而在内存资源紧缺的情况下,应该以何种次序终止哪些 Pod 对象就变成了问题。

事实上,Kubernetes 无法自行对此做出决策,它需要借助于 Pod 对象的服务质量和优先级等完成判定。根据 Pod 对象的 requestslimits 属性,Kubernetes 把 Pod 对象归类到 BestEffort、Burstable 和 Guaranteed 这 3 个服务质量类别(Quality of Service,
QoS)下。

  • Guaranteed: Pod 对象为其每个容器都设置了 CPU 资源需求和资源限制,且二者具有相同值;同时为每个容器都设置了内存需求和内存限制,且二者具有相同值。这类 Pod 对象具有最高级别服务质量。
  • Burstable:至少有一个容器设置了 CPU 或内存资源的 requests 属性,但不满足 Guaranteed 类别的设定要求,这类 Pod 对象具有中等级别服务质量。
  • BestEffort:不为任何一个容器设置 requestslimits 属性,这类 Pod 对象可获得的服务质量为最低级别。

一旦内存资源紧缺,BestEffort 类别的容器将首当其冲地被终止,因为系统不为其提供任何级别的资源保证,但换来的好处是,它们能够做到尽可能多地占用资源。若此时系统上已然不存任何 BestEffort 类别的容器,则接下来将轮到 Burstable 类别的 Pod 被终止。

Guaranteed 类别的容器拥有最高优先级,它们不会被杀死,除非其内存资源需求超限,或者 OOM 时没有其他更低优先级的 Pod 对象存在。

每个运行状态的容器都有其 OOM 评分,评分越高越优先被杀死。OOM 评分主要根据两个维度进行计算:由服务质量类别继承而来的默认分值,以及容器的可用内存资源比例,而同等类别的 Pod 对象的默认分值相同。

因此,同等级别优先级的 Pod 资源在 OOM 时,与自身的 requests 属性相比,其内存占用比例最大的 Pod 对象将先被杀死。

需要特别说明的是,OOM 是内存耗尽时的处理机制,与可压缩型资源 CPU 无关,因此 CPU 资源的需求无法得到保证时,Pod 对象仅仅是暂时获取不到相应的资源来运行而已。

# Kubernetes  

如果这篇文章对您有帮助,可点击下方链接分享给你的朋友们😋,如果遇到问题欢迎评论、留言~~~😇

评论

公众号:zze_coding

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×