K8s Pod 中断预算 (PDB) 与应用稳定性 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

好嘞！系好安全带，咱们这就开始一段关于 Kubernetes Pod Disruption Budget (PDB) 的奇妙旅程，保证让你从云里雾里到胸有成竹，应用稳定性蹭蹭上涨！

Kubernetes PDB：应用稳定性的守护神，了解一下？

各位观众，晚上好！我是今晚的讲师，江湖人称“代码界段子手”。今天咱们不聊高深莫测的架构，不谈玄之又玄的理论，就来聊聊 Kubernetes 里一个既重要又容易被忽略的小家伙——Pod Disruption Budget (PDB)。

想象一下，你的应用就像一位脆弱的艺术家，需要一个安静、稳定的创作环境。而 Kubernetes 集群就像一个嘈杂、充满活力的工作室，各种操作（升级、节点维护、自动缩放）随时可能发生，一不小心就会打断艺术家的灵感（导致服务中断）。

PDB，就是这位艺术家的贴身保镖，专门负责在这些干扰因素发生时，保护你的应用，确保它不会被轻易打断。

什么是 Pod Disruption Budget？

简单来说，PDB 是一种 Kubernetes 资源，它定义了在自愿中断（Voluntary Disruption）期间，允许有多少个 Pod 同时不可用。所谓 “自愿中断” 指的是 Kubernetes 集群管理员或自动化工具主动发起的中断，例如：

节点维护：为了安全性和性能，需要定期重启或升级节点。
节点 Drain：将节点上的所有 Pod 驱逐出去，以便进行维护或移除。
集群升级：升级 Kubernetes 版本。
自动缩放：Kubernetes HPA (Horizontal Pod Autoscaler) 根据负载自动调整 Pod 数量。

PDB 就像一道屏障，告诉 Kubernetes： “嘿，哥们儿，这些 Pod 很重要，你最多只能同时中断 X 个，或者百分之 Y 个，否则会影响我的服务质量！”

为什么我们需要 PDB？

有了 PDB，你就能在集群维护和应用稳定性之间找到一个平衡点。如果没有 PDB，那么 Kubernetes 在进行上述操作时，可能会毫不留情地驱逐你的所有 Pod，导致服务完全不可用。

这就像一场突如其来的龙卷风，把你的房子吹得七零八落，甚至夷为平地。

有了 PDB，情况就大不一样了。 Kubernetes 会尽最大努力遵循 PDB 的限制，确保至少有一定数量的 Pod 保持运行，从而保证服务的可用性。

这就像给你的房子加了一道防风墙，即使外面狂风暴雨，房子也能屹立不倒。

PDB 的工作原理

PDB 的核心思想是定义一个最小可用 Pod 数量或最大不可用 Pod 数量。 Kubernetes 会在进行自愿中断操作时，检查 PDB 的配置，并确保不会违反这些限制。

PDB 使用 Pod 选择器 (selector) 来确定它保护哪些 Pod。选择器就像一个过滤器，只有符合条件的 Pod 才会受到 PDB 的保护。

举个例子，假设你的应用使用标签 app=my-app 来标识 Pod。你就可以创建一个 PDB，使用 app=my-app 作为选择器，这样 PDB 就会保护所有带有这个标签的 Pod。

如何创建 PDB？

PDB 是一个 Kubernetes 资源，可以用 YAML 文件来定义。下面是一个简单的 PDB 示例：

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  minAvailable: 2  # 至少保持 2 个 Pod 可用
  selector:
    matchLabels:
      app: my-app

这个 PDB 定义了：

apiVersion: policy/v1，指定 PDB 的 API 版本。
kind: PodDisruptionBudget，指定资源类型为 PDB。
metadata.name: my-app-pdb，指定 PDB 的名称。
spec.minAvailable: 2，指定至少保持 2 个 Pod 可用。
spec.selector.matchLabels.app: my-app，指定 PDB 保护带有 app=my-app 标签的 Pod。

你也可以使用 maxUnavailable 来定义最大不可用 Pod 数量：

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  maxUnavailable: 1  # 最多允许 1 个 Pod 不可用
  selector:
    matchLabels:
      app: my-app

这个 PDB 定义了最多允许 1 个 Pod 不可用。

minAvailable 和 maxUnavailable 的区别：

minAvailable: 指定必须始终可用的 Pod 数量。
maxUnavailable: 指定可以容忍的最大不可用 Pod 数量。

你可以根据你的应用需求选择使用哪个参数。如果你的应用对可用性要求非常高，建议使用 minAvailable。如果你的应用可以容忍一定程度的不可用，可以使用 maxUnavailable。

更灵活的表达方式：

minAvailable 和 maxUnavailable 也可以使用百分比来表示。例如：

spec:
  minAvailable: "50%"  # 至少保持 50% 的 Pod 可用

这意味着至少要保持 50% 的 Pod 处于可用状态。如果你的应用有 4 个 Pod，那么至少要保持 2 个 Pod 可用。

注意： 百分比是相对于 Pod 总数的。

PDB 的适用场景

PDB 适用于各种有状态和无状态应用，特别是那些对可用性要求较高的应用。一些常见的适用场景包括：

数据库：数据库通常需要保证高可用性，以避免数据丢失。
消息队列：消息队列需要保证消息的可靠传递，避免消息丢失。
缓存服务：缓存服务需要保证数据的快速访问，避免服务降级。
微服务：微服务架构中，各个服务之间相互依赖，任何一个服务的故障都可能导致整个系统崩溃。

总而言之，只要你的应用需要保证高可用性，就应该考虑使用 PDB。

PDB 的局限性

PDB 并不是万能的。它只能防止自愿中断，不能防止非自愿中断（Unvoluntary Disruption）。

什么是 “非自愿中断” 呢？

非自愿中断指的是 Kubernetes 无法控制的中断，例如：

节点故障：节点硬件故障、操作系统崩溃等。
网络故障：网络连接中断。
内核 Panic：操作系统内核发生严重错误。

这些故障是突发性的，Kubernetes 无法提前预知，也无法阻止。

PDB 的限制：

PDB 不能保证 100% 的可用性。即使你配置了 PDB，也仍然可能因为非自愿中断而导致服务不可用。
PDB 不能阻止节点 Drain 操作。如果 Kubernetes 必须要 Drain 一个节点，即使违反了 PDB 的限制，也会强制执行。但是，Kubernetes 会尽最大努力遵循 PDB 的限制，尽量减少对应用的影响。
PDB 只能保护由 Deployment、StatefulSet 等控制器管理的 Pod。如果你直接创建 Pod，没有使用控制器，那么 PDB 将不会生效。

PDB 的最佳实践

仔细评估你的应用需求：在配置 PDB 之前，你需要仔细评估你的应用对可用性的要求。你需要考虑你的应用可以容忍的最大不可用时间，以及最小可用 Pod 数量。
选择合适的 minAvailable 或 maxUnavailable 值： minAvailable 和 maxUnavailable 的值需要根据你的应用需求进行调整。如果你对可用性要求非常高，建议使用较小的 maxUnavailable 值。如果你可以容忍一定程度的不可用，可以使用较大的 maxUnavailable 值。
使用 Pod 选择器：使用 Pod 选择器来精确地指定 PDB 保护哪些 Pod。确保选择器能够匹配到所有需要保护的 Pod。
监控 PDB 的状态：监控 PDB 的状态，确保它能够正常工作。你可以使用 kubectl get pdb 命令来查看 PDB 的状态。
结合其他高可用方案： PDB 只是 Kubernetes 高可用方案的一部分。你还需要结合其他高可用方案，例如多副本部署、跨可用区部署、自动故障转移等，才能构建一个真正高可用的应用。

PDB 的进阶技巧

使用 DisruptionTarget 注解：你可以使用 DisruptionTarget 注解来指定 PDB 保护哪些类型的自愿中断。例如，你可以只保护节点维护操作，而不保护自动缩放操作。
使用 PodTopologySpread 约束：你可以使用 PodTopologySpread 约束来控制 Pod 在不同拓扑域（例如节点、可用区）上的分布。这可以提高应用的容错能力。
使用 PriorityClass 优先级类：你可以使用 PriorityClass 优先级类来定义 Pod 的优先级。高优先级的 Pod 会比低优先级的 Pod 更不容易被驱逐。

总结

PDB 是 Kubernetes 中一个非常重要的资源，它可以帮助你提高应用的可用性。通过合理地配置 PDB，你可以在集群维护和应用稳定性之间找到一个平衡点，确保你的应用能够持续稳定地运行。

用一张表格来总结一下 PDB 的关键点：

特性	描述
功能	定义在自愿中断期间，允许有多少个 Pod 同时不可用，从而保护应用的稳定性。
适用场景	数据库、消息队列、缓存服务、微服务等对可用性要求较高的应用。
局限性	只能防止自愿中断，不能防止非自愿中断。
配置参数	`minAvailable` (最小可用 Pod 数量) 或 `maxUnavailable` (最大不可用 Pod 数量), 可以使用数量或百分比表示。
选择器	使用 Pod 选择器来确定 PDB 保护哪些 Pod。
最佳实践	仔细评估应用需求，选择合适的配置参数，监控 PDB 状态，结合其他高可用方案。
进阶技巧	使用 `DisruptionTarget` 注解、`PodTopologySpread` 约束、`PriorityClass` 优先级类来进一步优化 PDB 的行为。

希望今天的分享能够帮助你更好地理解 PDB，并将其应用到你的 Kubernetes 项目中。记住，PDB 就像一位忠诚的保镖，时刻守护着你的应用，让它在云端稳定运行！

最后，送给大家一句代码界的箴言：

“代码千万行，稳定第一行。PDB 不配置，上线泪两行。”

感谢大家的聆听！咱们下期再见！