一个封锁操作被对 wsacancelblockingcall 的调用中断_k8s Pod进阶（五）：Pod中断

适用人群

1. 想要构建高可用性应用程序的所有者

2. 自动执行群集操作(如升级和自动缩放群集)的群集管理员

中断类型

Pod中断分为自愿和非自愿中断。

Pod 一般不会自动消失，直到有人或控制器将其销毁，或者出现不可避免的硬件或系统软件错误。这些不可避免的情况称为非自愿性中断。例如：

• 后端节点物理机的硬件故障
• 集群管理员错误地删除虚拟机(实例)
• 云提供商或虚拟机管理程序故障导致VM实例消失
• 内核恐慌(kernel panic)如：硬件问题、系统过热、文件系统紊乱及内核更新等
• 由于群集网络分区，节点从群集中消失
• 由于节点资源不足而将Pod逐出

以上情况除资源不足外，其他情况(不是Kubernetes特有的)大多数用户都应熟悉。

非自愿中断的情况外，其他情况称为自愿中断。包括应用程序所有者和群集管理员发起的操作。

典型应用程序所有者操作包括：

• 删除管理Pod的deployment或controller
• 更新了 Deployment 的 Pod 模板导致 Pod 重启
• 直接删除 Pod(意外删除)

集群管理员操作包括：

• 释放所有节点以便修复或升级
• 从群集中释放节点以缩小集群(缩容)
• 便于节点适合做其他事情，从节点中删除pod

这些操作可以由集群管理员直接执行，也可以由集群管理员或集群宿主提供的程序自动化执行。 可以通过咨询集群管理员或云提供商以及相关分发文档，来确定集群是否启用了任何自愿中断源。如果未启用，则可以跳过创建Pod中断预算(Disruption Budgets)。中断预算是Kubernetes提供的一组功能，这些功能可以在频繁的自愿中断的同时，保证运行高可用性应用程序。

注意：并非所有自愿中断都受到Pod Disruption Propgets的限制。例如，删除deployments或Pod会绕过Disruption Budgets。

中断处理

以下是一些缓解非自愿中断的方法：

• 确保pod 要求所需的资源。
• 如果需要更高的可用性，请复制应用程序。
• 为了在运行复制的应用程序时获得更高的可用性，可以跨机架或跨区域分布应用程序 。

自愿中断的频率各不相同。在基本的Kubernetes集群上，根本没有自愿中断。但是，群集管理员或托管服务提供商可能会运行一些导致自愿中断的其他服务。例如，推出节点软件更新可能会导致自愿中断。此外，集群(节点)自动缩放的某些实现可能会导致碎片整理和紧缩节点的自愿中断。集群管理员或托管服务提供商应记录预期的自愿中断级别(如果有)。

中断预算如何运作

应用程序所有者可以为每个应用程序创建一个 PodDisruptionBudget 对象(PDB)。PDB限制一个复制应用程序由于自愿中断而同时宕掉的pod的个数。例如，基于仲裁的应用程序希望确保运行的副本数量永远不会低于仲裁所需的数量。Web前端可能希望确保服务负载的副本数量永远不会低于总数的某个百分比。

集群管理员和托管提供商应使用遵守Pod Disruption Budgets，调用驱逐API 而不是直接删除pod或deployments的工具。如：kubectl drain命令和Kubernetes-on-GCE集群升级脚本(cluster/gce/upgrade.sh)。

当集群管理员想要释放所有节点时，应使用kubectl drain命令。该命令试图驱逐机器上的所有pod。逐出请求可能被暂时拒绝，但该命令会定期重试所有失败的请求，直到所有pod终止，或者达到可配置的超时。

PDB指定应用程序可以容忍拥有的复制副本的数量(相对于其预期拥有的数量)。例如，指定spec.replicas: 5的Pod部署应该在任何给定时间具有5个pod。但如果其PDB允许每次只有4个，那么逐出API将允许一次Pod自愿中断而不是两个Pod。

组成应用程序的pod组使用标签选择器(label selector)指定，与应用程序控制器(部署，状态集等)使用的标签选择器相同。pod “预期”的数量是pods控制器根据.spec.replicas计算出来的。控制器可以从使用.metadata.ownerReferences对象的pod中找到。

PDB不能防止非自愿中断的发生，但它们也会计入中断预算。由于滚动升级应用程序而被删除或者变得不可用的Pod，确实会计入中断预算，但是在执行滚动升级时，控制器(如部署和有状态集)不受PDB限制 ，在控制器规范spec中配置了应用程序更新期间的故障处理。当使用逐出API逐出一个Pod时，它将被优雅地终止。参见《K8s Pod进阶(一)：优雅终止》。

PDB示例

有三个节点(node-1、node-2、node-3)的集群，群集正在运行多个应用程序。其中一个应用程序有3个副本(最初称 pod-a，pod-b和pod-c)。另一个应用程序与PDB无关的Pod，称为Pod-X。Pod布置如下：

3个pod都是部署deployment的一部分，共同拥有一个PDB，要求3个pod中至少有2个可用。例如，假设集群管理员想要重新启动到新的内核版本来修复内核中的错误。群集管理员首先尝试使用该kubectl drain命令释放node-1。该命令试图驱逐pod-a和pod-x且会立即成功。两个Pod同时进入terminating状态。这时集群处于以下状态：

部署控制器deployment 注意到其中一个pod正在终止，因此它会创建一个名为pod-d的Pod来替换Pod-a。此时，由于node-1是封锁的，deployment 会在另一个节点上。还将创建pod-y替代品pod-x。

(注意：对于状态集，pod-a(类似于pod-1)需要完全终止，然后才能创建替换pod-1替换后也称作pod-1，但具有不同的uid。

现在集群处于以下状态：

一段时间后，pod终止，集群看起来像这样：

此时，如果一个不耐烦的集群管理员试图释放node-2或者 node-3，释放命令(kubectl drain)将阻塞，因为部署deployment 只有2个可用的pod，并且其PDB至少需要2个Pod。经过一段时间后，pod-d变为可用。

群集状态现在看起来像这样：

现在，集群管理员试图释放node-2。drain命令将尝试以某种顺序驱逐两个pod，先说pod-b然后再说 pod-d。如果驱逐pod-b,它将成功驱逐。但是，当试图逐出pod-d时，它将被拒绝，因为这将只留下一个可用于部署的pod。部署deployment 创建了一个称为pod-e的pod-b替代品。由于集群中没有足够的资源来调度pod-e，因此drain命令将再次阻塞。群集可能最终处于此状态：

此时,集群管理员需要添加一个节点来让升级继续。

基于以下原因,将影响kubernetes控制中断的速度:

• 应用程序需要多少个副本
• 优雅地关闭实例需要多长时间
• 启动新实例需要多长时间
• 控制器的类型
• 集群的资源容量

分离群集所有者和应用程序所有者角色

通常，将集群管理者和应用程序所有者视为彼此对对方的知识了解相对局限的单独的角色是很有用的。这种职责分离意义在于：

• 当有许多应用程序开发团队共享Kubernetes集群时，需要一个专业化角色
• 当第三方工具或服务用于自动化群集管理时

Pod Disruption Budgets通过在角色之间提供接口来支持这种角色分离。

如果组织中没有这样的责任分离，则可能不需要使用Pod Disruption Budgets。

如何在集群中执行中断操作

如果群集管理员需要对群集中的所有节点执行中断操作，例如节点或系统软件升级，则可以使用以下选项：

• 在升级期间接受停机时间。
• 故障转移到另一个完整的副本群集。

-这样虽然没有停机时间，但对于复制节点和人力协调切换可能都是昂贵的。

• 编写容错中断应用程序并使用PDB。

-没有停机时间。

-最小的资源重复。

-允许更多自动化群集管理。

-编写能够容错中断的应用程序很困难，但是容忍自愿中断的工作在很大程度上与支持自动 缩放和容忍非自愿中断的工作重叠。

今天的分享就到这里，欢迎大家关注，收藏，转发，评论。谢谢大家支持！