干扰-PDB

1.简介

当管理员在对集群进行维护时（drain），会排空节点上的所有Pod，如果当前业务的所有Pod都在同一节点上时，执行drain操作会造成服务不可用，为了避免这一情况，我们需要使用PDB（干扰预算），来保障当前业务。

2.自愿干扰和非自愿干扰

Pod不会消失，除非有人（用户或控制器）将其销毁，或者出现不可避免的硬件或软件系统错误。

非自愿干扰

• 节点下层物理机的硬件故障
• 集群管理员错误地删除虚拟机
• 云提供商或虚拟机管理程序中的故障导致虚拟机消失
• 内核错误
• 节点由于集群网络隔离从集群中消失
• 由于节点资源不足导致pod被驱逐

除了资源不足的情况，以上情况都不是特定于Kubernetes的。

自愿干扰
包括应用所有者和集群管理员发起的
应用所有者：

• 删除控制器，导致Pod被摧毁
• 更新，导致Pod被重建
• 直接删除Pod（被控制器管理的Pod）
  集群所有者：
• 排空（drain）节点进行修复或升级

3.使用干扰预算

好处：

• 不停机
• 最小的资源重复
• 允许更多的集群管理自动化
• 编写可容忍干扰的应用程序是棘手的，但对于支持容忍自愿干扰所做的工作，和支持自动扩缩和容忍非自愿干扰所做工作相比，有大量的重叠

确定在自发干扰时，多少实例可以在短时间内同时关闭。

• 无状态的前端：
  • 关注：不能降低服务能力 10% 以上。
    • 解决方案：例如，使用 PDB，指定其 minAvailable 值为 90%。
• 单实例有状态应用：
  • 关注：不要在不通知的情况下终止该应用。
    • 可能的解决方案 1：不使用 PDB，并忍受偶尔的停机。
    • 可能的解决方案 2：设置 maxUnavailable=0 的 PDB。 意为（Kubernetes 范畴之外的）集群操作人员需要在终止应用前与用户协商， 协商后准备停机，然后删除 PDB 表示准备接受干扰，后续再重新创建。
• 多实例有状态应用，如 Consul、ZooKeeper 或 etcd：
  • 关注：不要将实例数量减少至低于仲裁规模，否则将出现写入失败。
    • 可能的解决方案 1：设置 maxUnavailable 值为 1(适用于不同规模的应用)。
    • 可能的解决方案 2：设置 minAvailable 值为仲裁规模（例如规模为 5 时设置为 3）。 (允许同时出现更多的干扰)。
• 可重新启动的批处理任务：
  • 关注：自发干扰的情况下，需要确保任务完成。
    • 可能的解决方案：不创建 PDB。任务控制器会创建一个替换 Pod

创建控制器：

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  # minAvailable 最小活跃数量   maxUnavailable 最大不可用的数量
  minAvailable: 2    # 支持整数或百分比（%）
  selector:
    matchLabels:
      app: zookeeper