kubernetes之服务质量

1.简介 在一个超用（容器limits总和大于系统容量上限）, 会导致操作系统的资源不足, 最终可能导致部分容器杀掉, 希望优先杀掉不太重要的容器 kubernetes把容器划分成3个等级, Guaranteed（完全可靠的）丶Burstable（较可靠的）和BestEffort（不太可靠的） kubernetes为了简化模式以及避免复杂性, QOS级别直接由Requests和Limits来定义

2.Guaranteed 如果pod中所有容器都定义了Limits和Requests, 并且所有容器的Limits的值和Requests值相等且不为0, 那么pod的级别就是为Guaranteed 容器可以不定义Requests, 因为Requests值在未定义时默认等于Limits

Guaranteed举例1：容器只指明了limits而未指明requests）。

containers: name: foo resources: limits: cpu: 10m memory: 1Gi name: bar resources: limits: cpu: 100m memory: 100Mi

Guaranteed举例2：requests与limit均指定且值相等。

containers: name: foo resources: limits: cpu: 10m memory: 1Gi requests: cpu: 10m memory: 1Gi name: bar resources: limits: cpu: 100m memory: 100Mi requests: cpu: 100m memory: 100Mi

3.Burstable 当一个pod既不为Guaranteed和BestEffort, 那么就是Burstable pod中的容器limit值与requests值不相等 pod中容器部分定义了limit值与requests值, 部分容器没有定义 Container bar没有指定resources

containers: name: foo resources: limits: cpu: 10m memory: 1Gi requests: cpu: 10m memory: 1Gi name: bar

Burstable举例2：对Container foo与bar不同的resources（foo为memory，而bar为cpu）设置了limits。

containers: name: foo resources: limits: memory: 1Gi name: bar resources: limits: cpu: 100m

Burstable举例3：Container foo没有设置limits，而bar requests与 limits均未设置。

containers: name: foo resources: requests: cpu: 10m memory: 1Gi name: bar

4.BestEffort Pod中所有容器都未定义Requests和Limits

5.QoS优先级 3种QoS优先级从有低到高（从左向右）： Best-Effort pods -> Burstable pods -> Guaranteed pods 参考文档： http://dockone.io/article/2592

转载于:https://www.cnblogs.com/lovelinux199075/p/11278728.html

相关资源：JAVA上百实例源码以及开源项目