PDB用于在节点轮转维护时确保核心组件最低可用数，如etcd需minAvailable:3、kube-apiserver需minAvailable:2；它仅限制kubectl drain等自愿中断，不防节点宕机；必须严格匹配Pod标签，推荐用minAvailable而非maxUnavailable以避免缩容导致仲裁失效。
要确保核心集群在节点轮转维护时维持最低可用水位线，关键不是“防所有中断”，而是用 PodDisruptionBudget（PDB）精准控制自愿性驱逐过程中可同时不可用的 Pod 数量。它不解决节点宕机、OOM 或误删，但能守住你定义的“底线”——比如 etcd 至少 3 个实例在线、API Server 至少 2 个副本响应请求。
以下是你实际落地时最需关注的四点：
明确核心组件的最小仲裁/服务水位
每个核心系统有其“不可降级”的最小运行规模：
- etcd 集群（5 节点）：仲裁要求 ≥3，因此
minAvailable: 3是硬约束 - kube-apiserver（Deployment，6 副本）：至少需 2 个健康实例对外提供读写，设
minAvailable: 2 - CoreDNS（StatefulSet，4 副本）：DNS 查询强依赖连续性，建议
minAvailable: 3（容忍单点失效） - Prometheus（1 副本常见）：若仅部署单实例，
minAvailable: 1是唯一选择；否则应避免单点，改用多副本 + PDB
只对自愿中断生效，必须匹配真实运维动作
PDB 只拦截这些操作：
-
kubectl drain node-xx（节点腾空） - Cluster Autoscaler 缩容节点
- KubeSphere 或 RKE2 的节点升级流程
- 手动缩容 Deployment（如
kubectl scale deploy/kube-apiserver --replicas=4）
它不拦节点失联、内核 panic、磁盘满、OOM kill —— 这些靠多副本部署 + 反亲和（topologySpreadConstraints）+ 资源 limit + 监控告警兜底。
配置时严格绑定标签与控制器语义
PDB 不自动识别 Deployment，必须手动对齐：
- 确保
spec.selector.matchLabels和目标 Deployment 的spec.template.metadata.labels完全一致 - 若 Deployment 使用
app: kube-apiserver，PDB 就不能写app.kubernetes.io/name: kube-apiserver（除非 Deployment 真这么标） - 不支持模糊匹配或继承；标签错一个字符，PDB 就形同虚设
用 minAvailable 而非 maxUnavailable 守住底线
对核心控制平面组件，推荐统一使用 minAvailable：
- 语义清晰：“我不管总副本多少，你必须给我留 N 个活的”
- 避免百分比陷阱：
minAvailable: 80%在 5 副本时是 4，但在 HPA 触发缩容到 3 副本时变成 2（向下取整），可能跌破仲裁线 - 示例 YAML 片段（etcd 高可用）：
apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: etcd-ha-pdb namespace: kube-system spec: minAvailable: 3 selector: matchLabels: app: etcd
不复杂但容易忽略。
