2. 核心概念：PodDisruptionBudget（PDB）原理、minAvailable 与 maxUnavailable 策略、PDB 在版本升级中的作用

2.1 PodDisruptionBudget 原理与设计目标

PodDisruptionBudget（PDB）是 Kubernetes 提供的一种资源策略，用于在集群发生自愿中断（Voluntary Disruption）时，保护工作负载的可用性。在云原生日志平台中，日志采集 Agent（如 Fluentd、Vector）或日志处理 Pod 的连续可用性直接决定日志管道的完整性，PDB 正是为此类场景提供“最小存活保障”的核心机制。

PDB 的核心原理可概括为：在节点维护、集群升级、自动扩缩容等自愿中断操作发生时，PDB 通过约束同一时间最多可中断的 Pod 数量，确保工作负载始终维持指定的可用副本数。 其本质是一种准入控制与调度约束——当驱逐（Eviction）请求触发时，Kubernetes API Server 会检查目标 Pod 是否受 PDB 保护，若驱逐后可用副本数低于 PDB 阈值，则拒绝该驱逐操作。

2.2 minAvailable 与 maxUnavailable 策略

PDB 提供两种互斥的策略字段，用于定义工作负载的可用性边界。在日志平台版本漂移校准场景中，正确选择策略类型直接影响升级过程中的日志采集连续性。

2.2.1 minAvailable 策略详解

minAvailable 定义的是下限保护。当集群调度器或节点控制器准备驱逐一个 Pod 时，会计算当前工作负载的可用 Pod 数量。如果驱逐后可用 Pod 数低于 minAvailable，则驱逐被拒绝。

# 示例：日志采集 DaemonSet PDB，要求至少保留 2 个可用 Pod
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: log-agent-pdb
  namespace: logging
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: log-agent

在版本漂移校准场景中，若集群有 10 个日志采集 Pod，设置 minAvailable: 9 意味着同一时间最多只能有 1 个 Pod 被驱逐，从而保证 90% 的采集能力在线。这种保守策略适用于日志采集不可中断的金融、实时监控等场景。

2.2.2 maxUnavailable 策略详解

maxUnavailable 定义的是上限容忍。它直接指定最多允许多少个 Pod 同时处于不可用状态，而不关心剩余可用 Pod 的具体数量。这种策略在滚动升级场景中更为灵活。

# 示例：日志处理 Deployment PDB，允许最多 1 个 Pod 不可用
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: log-processor-pdb
  namespace: logging
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app: log-processor

当工作负载副本数较大时，使用百分比形式更合理。例如 maxUnavailable: 25% 表示最多允许 25% 的 Pod 同时不可用，Kubernetes 会向上取整计算值。

2.3 PDB 在版本升级中的作用

在云原生日志平台的版本漂移校准场景中，PDB 扮演着“安全护栏”的角色。版本升级（包括集群节点升级、Kubernetes 版本升级、日志 Agent 自身版本升级）都属于自愿中断操作，PDB 通过以下机制保障日志管道的稳定性：

1. 控制升级速率： PDB 限制同一时间被驱逐的 Pod 数量，防止升级操作一次性中断过多日志采集实例，导致日志数据丢失或采集延迟。
2. 保障采集连续性： 对于 DaemonSet 部署的日志 Agent，PDB 确保每个节点或关键节点组至少保留一个采集 Pod，避免出现“采集盲区”。
3. 版本漂移检测窗口： 在版本升级过程中，PDB 的约束使得新旧版本 Pod 共存时间延长，为版本漂移校准提供更充分的观测窗口。
4. 回滚安： 当升级导致日志采集异常时，PDB 阻止进一步的驱逐操作，为运维人员争取回滚时间，避免故障扩散。

2.3.1 版本升级中的 PDB 工作流程

以下流程展示了在日志平台版本升级过程中，PDB 如何与节点排水（Node Drain）和 Pod 驱逐协同工作：

2.3.2 日志平台版本升级 PDB 配置建议

针对云原生日志平台的不同组件，PDB 配置策略应有所差异：

• 日志采集 Agent（DaemonSet）： 使用 minAvailable 策略，建议值 max(1, 节点数 - 1) 或 minAvailable: 90%。确保每个节点升级时，其他节点的采集能力不受影响。
• 日志处理/聚合服务（Deployment）： 使用 maxUnavailable 策略，建议值 1 或 25%。允许少量处理 Pod 离线以加速滚动升级，同时保证处理能力不出现明显下降。
• 日志存储组件（StatefulSet）： 使用 minAvailable 策略，建议值 副本数 - 1。对于有状态组件，数据完整性优先于升级速度。