资源的分类 可压缩资源，例如CPU，当其不足时，Pod只会“饥饿”等待，而不会退出 不可压缩资源，例如内存，当其不足时，Pod会被内核kill yaml中资源的单位 CPU：一般写作cpu:“500m”，表示500milicpu，意味着0.5cpu，也可以直接写成cpu:0.5，但这种写法不通用，仍建议使用m为单位 内存：默认单位时bytes，例如memory:500Mi，意味着内存为50010241024bytes；memory:100M意味着内存为50010001000bytes 定义资源限制时，还分limits和requests两种 在调度的时候，kube-scheduler 只会按照 requests 的值进行计算 在真正设置 Cgroups 限制的时候，kubelet 则会按照 limits 的值来进行设置 类似**Borg 论文中对“动态资源边界”**的思想（刚提交作业时，其所需资源一般远小于他的资源限额，所以刚提交时会主动减小其资源限额，以提升效率，当资源用量提升到一定阈值时再“快速恢复”） kubernetes的QoS模型，给Pod划分为几个QoS级别： Guaranteed： Pod 里的每一个 Container 都同时设置了 requests 和 limits，并且 requests 和 limits 值相等（若仅设置了limits没有设置requests，kubernetes会自动设置与limits取值相同的requests） Burstable：Pod 不满足 Guaranteed 的条件，但至少有一个 Container 设置了 requests BestEffort：Pod 既没有设置 requests，也没有设置 limits 当宿主机资源紧张的时候，kubelet 会对 Pod 进行 Eviction（即资源回收） 比如，可用内存（memory.available）、可用的宿主机磁盘空间（nodefs.available），以及容器运行时镜像存储空间（imagefs.available）等等 Eviction 在 Kubernetes 里分为 Soft 和 Hard 两种模式。 Soft Eviction 允许设置一段“优雅时间”，达到阈值持续一段时间才会触发Eviction Hard Eviction 模式下，Eviction 过程就会在阈值达到之后立刻开始。 Eviction时，kubelet根据Pod的QoS级别来决定回收哪些Pod: 首先选择 BestEffort 类别的 Pod 其次是Burstable 类别中资源使用量超过requestes的Pod 最后是Guaranteed类别中资源使用量超过limits的，或者宿主机内存紧张的Pod 建议将DaemonSet的Pod都设置为Guaranteed级别，不然一旦被回收又会立刻重建，令资源回收失去意义 cpuset的设置 通过cpuset的设置，可将容器绑定到某个CPU核心上，无需共享CPU，减小OS在CPU之间切换的开销，提高容器中应用性能 设置方式：保证Pod是Guaranteed类别，且CPU的requests和limits是相同的整数
