kubernetes中断预算的实现原理是什么，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。
创新互联建站是一家专注于网站建设、成都网站设计与策划设计,海拉尔网站建设哪家好?创新互联建站做网站,专注于网站建设十年,网设计领域的专业建站公司;建站业务涵盖:海拉尔等地区。海拉尔做网站价格咨询:18982081108
驱逐这个概念在k8s中个人理解有两种场景：apiserver端的Pod驱逐接口和kubelet里面的驱逐管理器，两者虽然都有类似的evictPod的操作，但本质上却根本不是一个东西, 在kubelet里面的驱逐最终会调用runtime来kill掉正在运行的容器, 而apiserver端的接口则是直接在etcd里面删除对应的Pod, 也是PDB真正起作用的地方, 本文后面的驱逐都是指的apiserver端的接口
drain是k8s用于维护节点扩容的时候的一个命令，事实上默认在k8s中也就只有该命令会进行驱逐接口的调用了
Pod中断预算名字很直白但看介绍是真复杂， 其实简单来说可以分为两部分：中断和预算，预算其实很容易理解，就跟大家平常花钱一样，有多少预算买多少钱的东西，这里的预算也是一样，不过这里的预算是你可以进行操作的数量，比如你允许某个资源的最多10%的Pod宕机，它就会根据你当前的状态和你的预算来计算出，你可以中断多少机器
那什么是中断呢？答案就是删除对应的操作其实就是删除对应的Pod, 整合在一起其实就是根据你当前的状态计算出你可以进行删除Pod操作的数量
好了基础概念就介绍到这里，下面开始其实现的探索
我们上面提到了PDB的本质就是计算允许进行删除操作的数量，那要进行这种计算需要那些数据呢？首先我们需要一个PDB(预算)，然后我们需要当前Pod的状态(通过selector)这部分是不是够了呢？答案肯定不是，还缺什么呢？就是我们上面提到的total，即该Pod当前集群中期望有几个，如何获取呢？其实这个对应的就是对应的上层资源，比如Deployment、ReplicaSet、StatefulSet等，我们需要渠道对应上层资源期望的Pod的数量，也就是我们的total
那么如何我才能知道我Pod的管理的上层控制器具体是谁呢？答案其实就是Controlled By字段我们可以获取对应的ownerReferences这样我们就可以知道上层的控制器是谁，然后我们就可以从对应控制器字段里面取出对应的期望的数量
中断有效时间这个名字我感觉很贴切，官方的名字叫DeletionTImeout，因为在k8s里面控制器和apiserver是可以分开的两个组件，上面我提到了驱逐接口会接收到驱逐请求，那怎么把这种驱逐的Pod传递给PDB呢
因为他要计算还可以继续驱逐多少，除了当前的Pod和期望的Pod数量之外，也肯定需要知道当前还可以继续已经被中断(正在进行驱逐的)的数量
如果因为集群的不稳定造成PDB过了很久才收到这条消息，实际上对应的请求可能早就已经失效了，则对应的被驱逐的Pod实际上并没有被驱逐计算的时候还依旧将其计算在内，则可能会影响后续的驱逐操作，所以为了解决这种延迟和不同步问题，才有了中断有效时间，默认是2分钟，过期后就会自动删除，并且计算的时候就会跳过该Pod
控制整体实现分为如下几个大的步骤：1.用户定义PDB要保护的资源2.controller感知资源然后计算PDB对应的数据3.eviction接口接收到驱逐请求后,检测PDB是否允许，如果允许就更新中断的Pod到PDB的DisruptedPods字段中4.PDB感知到更新之后，重新进行计算更新PDB，这样eviction下次接收到驱逐请求之后就可以使用，反反复复
看完上述内容，你们掌握kubernetes中断预算的实现原理是什么的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注创新互联行业资讯频道，感谢各位的阅读！
