Helm 报 PodDisruptionBudget policy/v1beta1 不存在：修正真正的模板

Helm 安装或升级时，清单构建阶段报 no matches for kind "PodDisruptionBudget" in version "policy/v1beta1"。先核对服务器提供的 API，以及 chart 最终渲染出的 PDB。单独创建一份 policy/v1 PDB，不会改变 chart 继续提交旧版本模板的行为。

Kubernetes 1.25 起不再提供 PDB 的 policy/v1beta1 API；policy/v1 从 1.21 起可用。本文针对旧 chart 与当前集群不兼容的分支。尚未核对集群与清单时，不能只凭所有“no matches”错误都判断为这次版本移除。

找渲染结果，不必先找到某个固定文件名

先用只读命令确认正在访问的集群：

kubectl config current-context
kubectl version
kubectl api-versions

关注服务器版本，以及是否提供 policy/v1。若连接的是错误集群，先修正上下文；若 API 发现请求本身失败，先处理权限或连接错误，不能把失败的发现结果当作该 API 不存在。

PDB 可能来自主 chart、子 chart 或打包的依赖，不一定在当前目录下叫 poddisruptionbudget.yaml。下面是本地渲染结构示例，名称、目录、values 与命名空间需与实际安装对应：

helm template example-release ./chart \
  --namespace team-app -f values.yaml

查看输出中 kind: PodDisruptionBudget 相邻的 apiVersion，以及 Source 注释提示的模板位置。输出也可能包含 Secret 等敏感配置，按受限资料保管。需要保存时使用受控位置，不写进公共仓库。

本地渲染不会替服务器验证 API 是否支持。依赖 Capabilities 选择版本的 chart，还需按实际服务器设置 kube-version 或 api-versions；升级分支应同时核对 is-upgrade 等与实际操作相关的条件。不要把默认渲染与线上升级视为完全相同的执行环境。

若已有 release，可以读取其保存的清单辅助比较：

helm get manifest example-release --namespace team-app

它给出已有修订生成的资源，不代表当前准备升级的 chart 内容；首次安装失败，也可能没有可读取的历史。重点仍是找到这一次实际提交旧 API 的模板及其依赖版本。

更新兼容 chart，并保留原来的保护范围

优先选择产品支持、与目标 Kubernetes 兼容的 chart 版本，同时核对应用、CRD 和持久数据的升级要求。需要维护自己的 chart 时，在真正生成 PDB 的模板中使用 policy/v1，并保存依赖锁定信息。不要只修改下载目录里一次性的副本，下一次部署又还原。

下面是 policy/v1 PDB 的结构示例，保护范围和预算必须按应用要求确定：

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: example-api
  namespace: team-app
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: example-api

这里的标签应准确匹配计划保护的 Pod。policy/v1 中 selector: {} 会选择该命名空间所有 Pod；在旧 policy/v1beta1 中，空选择器不选 Pod。没有设置 selector 则在两个版本中都不选 Pod。迁移时必须保留预期范围，不能只替换 apiVersion 后略过这一差异。

minAvailable 与 maxUnavailable 应按业务选择一种。示例不是所有应用的推荐预算：单副本且 minAvailable 为 1 会限制后续自愿驱逐，有状态集群还需满足仲裁条件。API 兼容性修好后，预算配置仍需单独核对。

不用关闭 PDB 掩盖模板不兼容

部分 chart 提供禁用 PDB 的选项。它可能绕开这一个旧对象，却改变节点维护期间的保护，且 chart 还可能包含其他已移除 API。除非已确认业务允许这种变化，否则不应作为正常兼容修复。

--disable-openapi-validation 也不会让服务器重新提供已删除的 API。PDB 属于 Kubernetes 内置资源，不是靠安装同名 CRD 补回的扩展类型。不要为旧清单降级生产集群，先修正产品支持的模板版本。

变更前保存 chart 版本、values、依赖、release 历史与数据备份安排。重新渲染后确认所有 PDB 都使用受支持版本，再按项目既有服务端预检和发布流程执行。修改 chart 可能连带更新工作负载，不能把它当作只改一个标签的无影响操作。

验收应确认安装或升级不再因旧 GVK 失败，实际 PDB 的标签范围和预算符合预期，应用副本与业务入口正常。需要回退时选择仍支持当前 Kubernetes 的审定修订；如果旧修订本身还提交 policy/v1beta1，直接回滚会再次遇到 API 兼容错误。