requests和limits
pod能够配置每个container的requests以标识资源申请额，配置limits以限度资源应用下限。
kubernetes依据requests，调度pod运行在哪个节点上。
kubernetes依据limits，限度pod能够应用cpu/memory资源:
- 当容器应用的cpu达到limits时，过程不会调配到更多的cpu；
- 当容器应用的memory达到limits时，容器会被OOMKilled，尝试重启；
apiVersion: v1Kind: Podmetadata: name: pod1spec: 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)
当遇到内存不足，BestEffort的Pod有多个，如何确定该kill哪个：
- 依据过程的OOM分数来抉择，分数越高，优先被杀掉；
- OOM分数：(理论内存使用量 / request.memory )的值越大，OOM分数越高；
如何确定pod Qos？
办法一：kubectl describe pod查问
# kubectl describe pod -n monitoring prometheus-k8s-0Name: prometheus-k8s-0Namespace: monitoring......QoS Class: Burstable......办法二：按上面的规定(举荐)
BestEffort:
- 所有的容器都没有调配requests和limits；
Guaranteed:
- 所有的容器都调配了requests和limits;
Burstable:
- 其它不属于BestEffort和Guaranteed的pod;
办法三：先判断container的Qos，再判断pod的qos
container的Qos判断办法：
pod的Qos判断办法：
参考：
- kubernetes in action