使用client-go操作PDB需注意：minAvailable与maxUnavailable互斥；创建前确认命名空间存在；优先用Apply()而非Update()；通过status.currentHealthy等字段验证实际生效；滚动更新时PDB与Deployment的maxUnavailable共同约束驱逐数量；删除前须检查关联工作负载及OwnerReferences。
怎么用 client-go 创建和更新 PDB 对象
直接调用 Kubernetes API 是最可控的方式，client-go 提供了 policyv1.PodDisruptionBudgetClient 接口。关键不是“管理预算”这个抽象概念，而是对 PodDisruptionBudget 这个具体资源的 CRUD 操作。
常见错误是把 minAvailable 和 maxUnavailable 同时写进 spec —— 它们互斥，Kubernetes 会拒绝这种 YAML，API 层报错 Invalid value: "both minAvailable and maxUnavailable are set"。
- 创建前先确认目标命名空间已存在，否则
Create()会返回NotFound错误，而不是静默失败 - 使用
Apply()（需启用 server-side apply）比Update()更安全，避免因字段未显式置空导致旧值残留（比如上次设了minAvailable: 3，这次只改selector却没清掉minAvailable，结果预算逻辑被意外保留） - 如果 PDB 的
selector匹配不到任何 Pod，status.currentHealthy会长期为 0，但不会报错；这容易让人误以为配置生效了，其实它根本没绑定到任何工作负载
如何用 Go 检查 PDB 是否真正生效
光创建成功不等于防护就起作用。必须验证 status 字段是否反映真实约束状态，尤其是 currentHealthy、desiredHealthy 和 disruptionsAllowed 这三个值。
典型误判场景：你设了 minAvailable: 3，Deployment 实际有 5 个 Pod 全部 Running，但 status.currentHealthy 显示 0 —— 很可能是因为 PDB 的 selector 和 Deployment 的 spec.selector.matchLabels 不一致，标签没对上。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
Get()获取 PDB 后，立刻检查Status.DisruptionsAllowed < 0：如果是负数，说明当前已有驱逐正在违反预算，集群已开始排队或拒绝新驱逐 -
desiredHealthy是根据minAvailable或maxUnavailable+ 当前匹配 Pod 总数实时算出来的，不是固定值；比如maxUnavailable: 25%在 4 个 Pod 时是 1，在 5 个 Pod 时还是 1（向下取整），别按浮点数理解 - 不要依赖
kubectl get pdb输出判断，它的MIN AVAILABLE列只显示原始配置值，不反映实际计算结果；得看describe或直接读Status
滚动更新时 PDB 为什么没拦住 Deployment 缩容
很多人发现给 Deployment 配了 PDB，但执行 kubectl rollout restart 或镜像更新后，Pod 还是瞬间全挂了。这是因为：PDB 确实参与校验，但 Deployment 自身的 maxUnavailable（滚动更新策略）优先级更高，且默认是 25%，它和 PDB 是两层独立控制。
例如你设了 maxUnavailable: 1 的 PDB，但 Deployment 的 strategy.rollingUpdate.maxUnavailable 是 2，那更新时最多可删 2 个 Pod —— 只要删完后还剩 ≥1 个健康 Pod（满足 PDB），操作就被允许。
- 真正起作用的是两者交集：
allowed = min(PDB.disruptionsAllowed, Deployment.maxUnavailable) - 如果你希望更新完全受 PDB 控制，就把 Deployment 的
maxUnavailable设成0或一个极小值，否则 PDB 只是兜底，不是强制闸门 -
kubectl drain场景下 PDB 是硬拦截：不满足就卡住，不会自动降级；但滚动更新是软协商，控制器会尝试找满足条件的路径
删除 PDB 前必须确认的三件事
删 PDB 不是简单执行 Delete() 就完事。它直接影响所有后续自愿中断行为的安全边界，尤其在线上环境。
最危险的操作是：在节点 drain 前临时删掉 PDB，以为“先腾空再补上”，结果 drain 过程中其他运维脚本也触发了缩容，副本数直接归零。
- 检查当前是否有正在进行的
drain或 CA（Cluster Autoscaler）驱逐：用kubectl get events --field-selector reason=Evicted查最近驱逐事件 - 确认关联的 Deployment/StatefulSet 副本数是否 > 1，且
readinessProbe正常 —— 否则删完 PDB 后，哪怕只驱逐 1 个 Pod，服务也可能彻底不可用 - 用
Get()拿到 PDB 对象后，先读OwnerReferences字段，避免误删由 Operator 自动管理的 PDB（比如 Argo CD 或自研 Operator 创建的）
terminationGracePeriodSeconds 和 readinessProbe 的配合比 PDB 本身更影响实际可用性。 
