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)
- 根据进程的OOM分数来选择，分数越高，优先被杀掉；
- OOM分数：(实际内存使用量 / request.memory )的值越大，OOM分数越高；
# kubectl describe pod -n monitoring prometheus-k8s-0Name:prometheus-k8s-0
Namespace:monitoring
......
QoS Class:Burstable
......方法二：按下面的规则(推荐) BestEffort:
- 所有的容器都没有分配requests和limits；
- 所有的容器都分配了requests和limits;
- 其它不属于BestEffort和Guaranteed的pod;
文章图片
【Kubernetes -- Pod的Qos分析】pod的Qos判断方法：
文章图片
参考：
- kubernetes in action
推荐阅读
- 热闹中的孤独
- JAVA（抽象类与接口的区别&重载与重写&内存泄漏）
- 放屁有这三个特征的，请注意啦！这说明你的身体毒素太多
- 一个人的旅行，三亚
- 布丽吉特，人生绝对的赢家
- 慢慢的美丽
- 尽力
- 一个小故事，我的思考。
- 家乡的那条小河
- 《真与假的困惑》???|《真与假的困惑》??? ——致良知是一种伟大的力量