这是由零停止时间在零停止时间重新续签的一系列文章的第四部分也是最后一部分。删除事件”，我们专注于如何正常关闭群集中的现有POD。我们介绍了如何使用PRESTOP钩正确关闭POD，以及为什么在POD关闭序列中添加延迟以等待删除删除很重要。可以在集群中传播的事件。这些事件可以处理POD的终止，但是不能保证我们可以在需要关闭多个POD时正常运行该服务这个风险。
翻译注意：PDB在Kubernetes中使用，以确保在群集中始终具有指定的POD副本的POD副本数量处于可用状态。它与部署中指定的指定的最大值不同。后者用于使用部署至少进行服务。它负责与尽快的欲望数量相同数量的实际副本，并且不会保证中间的实际副本数量。Kubernetes的PDB用于确保至少可以使用POD副本的数量在每时每刻，自愿（自愿）中断会做出良好的预算（预算解决方案）。
PDB专为自愿破坏场景而设计。它属于Kubernetes的可控类别之一，而不是为非自愿破坏而设计。自愿中断主要是某些系统维护和升级的操作，而不是自愿中断，通常均由某些硬件和网络故障引起。一些簇将自动管理节点，因此需要使用PDB来确保HA的应用。
POD中断预算（PDB）是可以在给定时间容忍的指标（故障预算）。在计算服务中的POD中断时，该服务将导致该服务降至PDB以下，将暂停操作，直到可以维持PDB。这意味着，在等待更多豆荚之前，您可以暂时停止豆荚，以避免驱逐POD并超出预算。
要配置PDB，我们需要在Kubernetes中创建一个资源对象（后来称为PDB对象）以匹配服务中的POD。始终保持至少一个POD可用，然后我们可以应用以下配置：
这将告诉Kubernetes。我们希望在任何时间点都有至少一个与标签相匹配的POD。使用此方法，我们可以宣传Kubernetes，以确保在自愿中断（更新/维护）避免服务关闭时至少可以使用一个POD。
为了解释PDB的工作原理，让我们返回我们一直使用的示例。简单性，在示例中，我们将忽略任何Prestop Hook，Ready Probe和Service请求。我们还假设我们要替换一个群集节点 --one。这意味着我们将使在新节点上运行和重建POD的节点数量增加一倍。
在图中，我们从两个节点的原始群集开始：
我们提供了两个其他节点来运行新的虚拟机镜像。在末端，在旧节点上运行的POD的新节点更换上创建了POD。
要替换服务POD所在的节点，我们首先需要清除旧节点。在本示例中，让我们看看如果您同时将命令发送到两个运行nginx Pod的节点，将会发生什么。节点将在两个线程中发出（实际上，您可以使用两个终端分别运行命令），每个线程管理节点的空执行顺序。
请注意，在这里，假设Kubectl Drain命令将立即发布驱逐出境请求。实际上，排水操作首先涉及标记节点（Noschedule标记），以便将POD放电到旧节点。
节点标记完成后，负责节点的线程在节点上启动POD。在此过程中，线程将首先转到控制中心查询，以查看Expelling POD是否会导致服务降至配置的PDB以下与豆荚数量。
应该在这里注意到，控制台将一次并发请求并处理PDB查询。在这种情况下，在这种情况下，控制平面将成功响应其中一个请求并使请求失败。这是因为第一个是因为第一个请求基于两个可用的POD。允许此请求将可用的POD数量减少到1，并维护PDB。当控制中心允许请求继续下去时，其中一个容器将被驱逐出来。，在处理第二个请求时，控制平面将拒绝它，因为允许请求将POD的数量减少到0，低于我们配置的PDB。
鉴于此，在示例中，我们假设节点1是成功响应的节点。在这种情况下，负责排除操作的线程将继续驱逐POD，而节点2的空行将等待并尝试尝试稍后：
当开发节点1上的NGINX POD时，将立即通过部署重建POD并计划到群集节点。由于已标记了群集的旧节点，调度程序将选择一个新节点进行调度。
此时，POD替换已在新节点上完成，并清空了原始节点Node1，并且用于空Node1的线程完成了任务。
从现在开始，当Node2的空线程转到控制中心以再次查询PDB时，它将成功响应。这是因为有一个运行的POD（Node3上新建的POD 3）没有考虑驱动序列。因此，Node2空线程将继续移动到PDB以下的POD数量。
在这一点上，我们在不遇到应用程序应用程序的情况的情况下成功地将两个POD迁移到了新节点。此外，我们不需要在两个线程之间对节点负责的协调逻辑。Kubernetes将根据我们提供的配置来处理所有作业！
在此博客系列中链接我们的内容，我们介绍了：
当将所有这些功能一起使用时，我们可以实现群集维护时零停机的目标！但是不要在这里听我说，继续在此处应用此处介绍的功能。
注意公共帐户“互联网管理BI”以获取更多选择的技术文章
作者：Kevinyan的版权属于作者。