摘要：中对容器的资源分配有三种策略。顾名思义是该容器对资源的最低要求和最高使用量限制。磁盘的使用不像有通过和进行配置，磁盘用量可以认为是一种策略为的资源。在这个时长范围内即便资源使用下降到阈值以下，也不会恢复。
QoS
k8s中对容器的资源分配有三种策略：
Guaranteed 。该策略下，pod.spec.containers[].resources中会存在cpu或memory的request和limit。顾名思义是该容器对资源的最低要求和最高使用量限制。如果我们配置了limit，没有配置request，默认会以limit的值来定义request。具体的配置可以参考以前的这篇笔记。
BestEffort。当pod的描述文件中没有resource.limit、resource.request相关的配置时，意味着这个容器想跑多少资源就跑多少资源，其资源使用上限实际上即所在node的capacity。
Burstable。当resource.limit和resource.request以上述两种方式以外的形式配置的时候，就会采用本模式。
QoS目前只用cpu和memory来描述，其中cpu可压缩资源，当一个容器的cpu使用率超过limit时会被进行流控，而当内存超过limit时则会被oom_kill。这里kubelet是通过自己计算容器的oom_score，确认相应的linux进程的oom_adj，oom_adj最高的进程最先被oom_kill。
Guaranteed模式的容器oom_score最小：-998，对应的oom_adj为0或1，BestEffort模式则是1000，Burstable模式的oom_score随着其内存使用状况浮动，但会处在2-1000之间。
因此我们可以看出，当某个node内存被严重消耗时，BestEffort策略的pod会最先被kubelet杀死，其次Burstable（该策略的pods如有多个，也是按照内存使用率来由高到低地终止），再其次Guaranteed。
kubelet的eviction机制完全依赖于oom_kill并不是一个很好的方案，一来对于cpu要求高的容器没有作用，二来单纯将pod杀死，并不能根本上解决困局，比如pod占用node绝大部分内存，加入pod被kill后再次调度到这个node上，oom的情况还会复现。所以kubelet增加了一套驱逐机制。
eviction机制适用于：
memory.available 、nodefs.available 、nodefs.inodesFree 、imagefs.available 、imagefs.inodesFree
分别对应于node目前可用内存、node上用于kubelet运行日志、容器挂载磁盘所使用的的文件系统的余量和inode余量、node上用于存放容器镜像和读写层的文件系统的余量、inode余量。
eviction中要设置触发驱逐的阈值Eviction Thresholds，这个阈值的配置可以是一个定值或一个百分比。如：
memory.available<10%
memory.available<1Gi
软驱逐机制表示，当node的内存/磁盘空间达到一定的阈值后，我要观察一段时间，如果改善到低于阈值就不进行驱逐，若这段时间一直高于阈值就进行驱逐。
这里阈值通过参数--eviction-soft配置，样例如上；观察时间通过参数--eviction-soft-grace-period进行配置，如1m30s。
另外还有一个参数eviction-max-pod-grace-period，该参数会影响到要被驱逐的pod的termination time，即终止该pod的容器要花费的时间。
强制驱逐机制则简单的多，一旦达到阈值，立刻把pod从本地kill，驱逐eviction-hard参数配置，样例亦如上。
pod eviction当资源使用情况触发了驱逐条件时，kubelet会启动一个任务去轮流停止运行中的pod，直到资源使用状况恢复到阈值以下。以硬驱逐为例，整体流程是：
每隔一段时间从cadvisor中获取资源使用情况，发现触发了阈值；
从运行中的pod里找到QoS策略最开放的一个，比如策略为bestEffort的一个pod（即便这个pod没有吃多少内存，大部分内存是另一个策略为burstable，但内存使用率也很高的pod），kubelet停止该pod对应的所有容器，然后将pod状态更新为Failed。如果该pod长时间没有被成功kill掉，kubelet会再找一个pod进行驱逐。
检查内存用量是否恢复到阈值以下，如果没有，则重复第二步（这里就要干掉那个罪魁祸首了）。一直到内存使用情况恢复到阈值以下为止。
有几个要注意的点是：
kubelet挑选pod进行驱逐的策略，就是按照QoS的策略开放度排序，而同一个QoS的多个pod中，kubelet会优先驱逐使用触发指标资源最多的一个。
磁盘的使用不像memory有通过request和limit进行配置，磁盘用量可以认为是一种QoS策略为BestEffort的资源。当触发磁盘资源不足时，kubelet会做一些额外的工作，比如清理已经dead的pod的容器日志，清理没有被使用的容器镜像，当然kubelet也会挑磁盘使用量（包括挂载本地volume空间+容器log大小,若是imagefs指标超额，此处还要加上容器运行时读写层的文件大小）最大的一个pod进行驱逐。
node condition
如上图，当软驱逐或者硬驱逐触发时，kubelet会尝试干掉一个pod，并且会将自身的状态从驱逐的指标信息中映射过来，比如内存使用超标触发驱逐，node的condtion就会变成memoryPressure，这个condition伴随的kubelet定时的心跳报文上传到master，记录在etcd中。在调度器进行调度时，会以这些condition作为调度条件的参考。比如，处于diskPressure的node，调度器就不会再将任何pod调度上去。否则一旦磁盘空间用满，node上的容器可能会严重崩溃。
但如果node的内存在阈值上下波动，condition被反复更新为pressure或正常，那么pod被误调度到node上也会很耽误事，所以用eviction-pressure-transition-period参数指定触发eviction后condition更新一次后要保留改状态的最小时长。在这个时长范围内即便资源使用下降到阈值以下，condition也不会恢复。
其他Minimum eviction reclaim 我们担心node可能驱逐了一个小pod后，指标就只是稍低于阈值，那么一旦其他pod的指标稍一上来，该node就又要进行eviction。所以用这个参数：
--eviction-minimum-reclaim(值如"memory.available=0Mi,nodefs.available=500Mi,imagefs.available=2Gi")进行限定，一旦发生了eviction，必须要保证node的某指标用量低于（该指标阈值-本参数指定的该指标值）才认为node恢复正常，否则还要接着驱逐pod。
简单的说，该参数表示的是node进行驱逐工作后要达到的效果是低于阈值多少。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/33037.html
摘要：将用户命令通过接口传送给，从而进行资源的增删改等操作。要使用编写应用程序，当下大多语言都可以很方便地去实现请求来操作的接口从而控制和查询资源，但本文主要是利用已有的客户端来更加优雅地实现的资源控制。 showImg(https://segmentfault.com/img/remote/1460000013517345); 【利用K8S技术栈打造个人私有云系列文章目录】 利用K8S...
摘要：将用户命令通过接口传送给，从而进行资源的增删改等操作。要使用编写应用程序，当下大多语言都可以很方便地去实现请求来操作的接口从而控制和查询资源，但本文主要是利用已有的客户端来更加优雅地实现的资源控制。 showImg(https://segmentfault.com/img/remote/1460000013517345); 【利用K8S技术栈打造个人私有云系列文章目录】 利用K8S...
摘要：去年换工作后，开始真正在生产环境中接触容器与。今天想先谈谈，我理解的容器是什么，以及为什么它们能火起来。一个容器镜像的实质就是程序进程加所有运行时环境及配置依赖的集合。这里再谈谈我理解的。而，就是目前的容器编排的平台的事实标准了。 去年换工作后，开始真正在生产环境中接触容器与Kubernetes。边恶补相关知识的同时，也想把学到的内容和自己的理解整理出来。学习的途径包括k8s官方文档...
摘要：去年换工作后，开始真正在生产环境中接触容器与。今天想先谈谈，我理解的容器是什么，以及为什么它们能火起来。一个容器镜像的实质就是程序进程加所有运行时环境及配置依赖的集合。这里再谈谈我理解的。而，就是目前的容器编排的平台的事实标准了。 去年换工作后，开始真正在生产环境中接触容器与Kubernetes。边恶补相关知识的同时，也想把学到的内容和自己的理解整理出来。学习的途径包括k8s官方文档...
摘要：如版本之前版本到版本之间版本之后一各种的含义该软件可能包含错误。启用一个功能可能会导致随时可能会丢弃对该功能的支持，恕不另行通知软件经过很好的测试。启用功能被认为是安全的。 本篇文章来自Terraform与Kubernetes中关于Deployment apps/v1的吐槽 Kubernetes的官方文档中并没有对apiVersion的详细解释，而且因为K8S本身版本也在快速迭代，有些...
摘要：但考虑到该用户在跨集群模式下的困扰，开始策划将托管云物理机纳入现有集群统一管理的方案，即在混合云架构下仅需部署管理一套集群。托管云物理机纳入UK8S集群统一管理后，可实现托管云物理机保障平峰时业务正常运行，高峰时期利用UK8S快速扩容公有云资源的理想应用场景，继而提升混合云的可用性。 ——海豹他趣技术负责人 张嵩 混合云的业务模式 厦门海豹他趣信息技术股份有限公司于2012年4...
阅读 2053·2021-11-11 16:55
阅读 1395·2021-09-28 09:36
阅读 1038·2019-08-29 15:21
阅读 1571·2019-08-29 14:10
阅读 2757·2019-08-29 14:08
阅读 1628·2019-08-29 12:31
阅读 3243·2019-08-29 12:31
阅读 976·2019-08-26 16:47
