kubernetes中断预算的实现原理是什么,相信很多没有经验的人对此束手无策,为此本文总结了问题出现的原因和解决方法,通过这篇文章希望你能解决这个问题。
<节> <节>
1.1驱逐到底是什么
<节> 
我们上面提到了PDB的本质就是计算允许进行删除操作的数量，那要进行这种计算需要那些数据呢？首先我们需要一个PDB(预算)，然后我们需要当前Pod的状态(通过selector)这部分是不是够了呢？答案肯定不是，还缺什么呢？就是我们上面提到的total，即该Pod当前集群中期望有几个，如何获取呢？其实这个对应的就是对应的上层资源，比如Deployment、ReplicaSet、StatefulSet等，我们需要渠道对应上层资源期望的Pod的数量，也就是我们的total
2.2 上层资源的关联
那么如何我才能知道我Pod的管理的上层控制器具体是谁呢？答案其实就是Controlled By字段我们可以获取对应的ownerReferences这样我们就可以知道上层的控制器是谁，然后我们就可以从对应控制器字段里面取出对应的期望的数量
2.3 中断有效时间
中断有效时间这个名字我感觉很贴切，官方的名字叫DeletionTImeout，因为在k8s里面控制器和apiserver是可以分开的两个组件，上面我提到了驱逐接口会接收到驱逐请求，那怎么把这种驱逐的Pod传递给PDB呢
因为他要计算还可以继续驱逐多少，除了当前的Pod和期望的Pod数量之外，也肯定需要知道当前还可以继续已经被中断(正在进行驱逐的)的数量
如果因为集群的不稳定造成PDB过了很久才收到这条消息，实际上对应的请求可能早就已经失效了，则对应的被驱逐的Pod实际上并没有被驱逐计算的时候还依旧将其计算在内，则可能会影响后续的驱逐操作，所以为了解决这种延迟和不同步问题，才有了中断有效时间，默认是2分钟，过期后就会自动删除，并且计算的时候就会跳过该Pod
2.4 整体实现大揭秘
控制整体实现分为如下几个大的步骤：1.用户定义PDB要保护的资源2.controller感知资源然后计算PDB对应的数据3.eviction接口接收到驱逐请求后,检测PDB是否允许，如果允许就更新中断的Pod到PDB的DisruptedPods字段中4.PDB感知到更新之后,重新进行计算更新PDB,这样驱逐下次接收到驱逐请求之后就可以使用,反反复复
