kubernetes 资源模型与资源管理

在kubernetes中pod是最小的原子调度单位，其中与调度密切相关的是pod资源相关的属性（CPU和Memory）。cpu和memory设置如下：

resources:
  requests:
    cpu: 100m
    memory: 100Mi
 limits:
   cpu: 100m
   memory: 100Mi

其中cpu这样的资源被成为可压缩资源，它的典型表现是，当可压缩资源不足时，pod不会退出。而Memory这样的资源则被称为不可压缩资源，当资源不足时Pod就会因为OOM（Out-Of-Memory）被杀掉。

值得注意的是，每个pod中可能由多个container组成，cpu和memory是在container上设置的，因此，pod整体资源限制是pod中容器资源配置的总和。

关于cpu和memory设置的一些注意事项：
在上述设置的代码片段中，cpu的值设置为100m，这代表是一个cpu核心的十分之一，memory设置的100Mi（1Mi=10241024，而1M=10001000）。

上述描述了在pod中的container上设置cpu和memory属性，这两个属性又关系到pod Qos。不同资源的设置使pod处于不同的级别，当node资源紧张时，此时会根据pod不同的级别做不同的处理。

当pod中的每一个container都同时设置了requests和limits，并且requests和limits值相等的时候，这个pod就属于Guaranteed类别：

resources:
  requests:
    cpu: 100m
    memory: 100Mi
 limits:
   cpu: 100m
   memory: 100M

在k8s集群中可以通过以下命令查看QoS：
kubectl describe po [podName] | grep QoS
值得注意的是当pod只设置了limits而没有requests，kubernetes会自动为它设置与limits相同的requests值。

当pod不满足Guaranteed级别时，但至少有一个container设置了requests，此时pod级别为Burstable。

resources:
  requests:
    memory: 200Mi
 limits:
   memory: 100M

而一个pod中既没有设置requests也没有设置limits，此时它的QoS类别就是BestEffort。

上面描述了因资源设置导致pod处于不同QoS类别，QoS的主要应用场景是当宿主机资源紧张时，kubelet对pod进行Eviction（资源回收）。
具体来说就是当node上的不可压缩资源紧张时，就可能触发Eviction。目前kubelet设置的Eviction的默认阈值如下：

memory.available<100Mi
nodefs.available<10%
nodefs.inodesFree<5%
imagefs.available<15%

其中当资源紧张触发Eviction时，Eviction又分为soft和hard两种模式，其中soft模式会根据设置的间隔时间有一定的缓冲期，当缓冲期过了之后才会进行开始Eviction，而hard模式会在触发Eviction时立即开始。

当触发Eviction时，pod的QoS此时就发挥作用了，kubelet会根据不同的级别来删除pod。首当其中的是BestEffort，其次是Burstable,最后才是Guaranteed。

附：当集群检测到node资源不足时，此时会给node打污点标记，禁止pod继续向该节点调度。~~~~
以上根据极客时间深入剖析kubernetes整理