特性状态： Kubernetes v1.21 [stable]
本文展示如何限制应用程序的并发干扰数量，在允许集群管理员管理集群节点的同时保证高可用。
您的 Kubernetes 服务器版本必须不低于版本 v1.21. 要获知版本信息，请输入 kubectl version。
用户想要保护通过内置的 Kubernetes 控制器指定的应用，这是最常见的使用场景：
在这种情况下，在控制器的 .spec.selector 字段中做记录，并在 PDB 的 .spec.selector 字段中加入同样的选择算符。
从 1.15 版本开始，PDB 支持启用 scale 子资源 的自定义控制器。
用户也可以用 PDB 来保护不受上述控制器控制的 Pod，或任意的 Pod 集合。
确定在自发干扰时，多少实例可以在短时间内同时关闭。
minAvailable 或 maxUnavailable 的值可以表示为整数或百分比。
如果将值指定为百分比，则可能无法映射到确切数量的 Pod。例如，如果你有 7 个 Pod， 并且你将 minAvailable 设置为 "50％"，具体是 3 个 Pod 或 4 个 Pod 必须可用 并非显而易见。 Kubernetes 采用向上取整到最接近的整数的办法，因此在这种情况下，必须有 4 个 Pod。 你可以检查控制此行为的 代码。
一个 PodDisruptionBudget 有 3 个字段：
.spec.selector 用于指定其所作用的 Pod 集合，该字段为必需字段。 .spec.minAvailable 表示驱逐后仍须保证可用的 Pod 数量。即使因此影响到 Pod 驱逐 （即该条件在和 Pod 驱逐发生冲突时优先保证）。 minAvailable 值可以是绝对值，也可以是百分比。 .spec.maxUnavailable （Kubernetes 1.7 及更高的版本中可用）表示驱逐后允许不可用的 Pod 的最大数量。其值可以是绝对值或是百分比。说明：
policy/v1beta1 和 policy/v1 API 中 PodDisruptionBudget 的空选择算符的行为 略有不同。在 policy/v1beta1 中，空的选择算符不会匹配任何 Pods，而 policy/v1 中，空的选择算符会匹配名字空间中所有 Pods。
用户在同一个 PodDisruptionBudget 中只能够指定 maxUnavailable 和 minAvailable 中的一个。 maxUnavailable 只能够用于控制存在相应控制器的 Pod 的驱逐（即不受控制器控制的 Pod 不在 maxUnavailable 控制范围内）。在下面的示例中， “所需副本” 指的是相应控制器的 scale，控制器对 PodDisruptionBudget 所选择的 Pod 进行管理。
示例 1：设置 minAvailable 值为 5 的情况下，驱逐时需保证 PodDisruptionBudget 的 selector 选中的 Pod 中 5 个或 5 个以上处于健康状态。
示例 2：设置 minAvailable 值为 30% 的情况下，驱逐时需保证 Pod 所需副本的至少 30% 处于健康状态。
示例 3：设置 maxUnavailable 值为 5 的情况下，驱逐时需保证所需副本中最多 5 个处于不可用状态。
示例 4：设置 maxUnavailable 值为 30% 的情况下，驱逐时需保证所需副本中最多 30% 处于不可用状态。
在典型用法中，干扰预算会被用于一个控制器管理的一组 Pod 中 —— 例如：一个 ReplicaSet 或 StatefulSet 中的 Pod。
说明： 干扰预算并不能真正保证指定数量/百分比的 Pod 一直处于运行状态。例如： 当 Pod 集合的 规模处于预算指定的最小值时，承载集合中某个 Pod 的节点发生了故障，这样就导致集合中可用 Pod 的 数量低于预算指定值。预算只能够针对自发的驱逐提供保护，而不能针对所有 Pod 不可用的诱因。
设置 maxUnavailable 值为 0%（或 0）或设置 minAvailable 值为 100%（或等于副本数） 可能会阻塞节点，导致资源耗尽。按照 PodDisruptionBudget 的语义，这是允许的。
用户可以在下面看到 pod 干扰预算定义的示例，它们与带有 app: zookeeper 标签的 pod 相匹配：
使用 minAvailable 的PDB 示例：
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: zk-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: zookeeper
使用 maxUnavailable 的 PDB 示例：
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: zk-pdb
spec:
maxUnavailable: 1
selector:
matchLabels:
app: zookeeper
例如，如果上述 zk-pdb 选择的是一个规格为 3 的 StatefulSet 对应的 Pod， 那么上面两种规范的含义完全相同。 推荐使用 maxUnavailable ，因为它自动响应控制器副本数量的变化。
你可以使用 kubectl 创建或更新 PDB 对象。
kubectl apply -f mypdb.yaml
PDB 对象无法更新，必须删除后重新创建。
使用 kubectl 来确认 PDB 被创建。
假设用户的名字空间下没有匹配 app: zookeeper 的 Pod，用户会看到类似下面的信息：
kubectl get poddisruptionbudgets
NAME MIN AVAILABLE MAX UNAVAILABLE ALLOWED DISRUPTIONS AGE
zk-pdb 2 N/A 0 7s
假设有匹配的 Pod (比如说 3 个), 那么用户会看到类似下面的信息：
kubectl get poddisruptionbudgets
NAME MIN AVAILABLE MAX UNAVAILABLE ALLOWED DISRUPTIONS AGE
zk-pdb 2 N/A 1 7s
ALLOWED-DISRUPTIONS 值非 0 意味着干扰控制器已经感知到相应的 Pod，对匹配的 Pod 进行统计， 并更新了 PDB 的状态。
用户可以通过以下命令获取更多 PDB 状态相关信息：
kubectl get poddisruptionbudgets zk-pdb -o yaml
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
anntation: {}
creationTimestamp: "2020-03-04T04:22:56Z"
generation: 1
name: zk-pdb
…
status:
currentHealthy: 3
desiredHealthy: 2
disruptionsAllowed: 1
expectedPods: 3
observedGeneration: 1
如果你只使用与内置的应用控制器（Deployment、ReplicationController、ReplicaSet 和 StatefulSet） 对应的 PDB，也就是 PDB 的选择算符与 控制器的选择算符相匹配，那么可以跳过这一节。
你可以使用这样的 PDB：它对应的 Pod 可能由其他类型的控制器控制，可能由 "operator" 控制， 也可能为“裸的（不受控制器控制）” Pod，但该类 PDB 存在以下限制：
.spec.minAvailable ，而不能够使用 .spec.maxUnavailable。 .spec.minAvailable 的值，而不能使用百分比。 你可以令选择算符选择一个内置控制器所控制 Pod 的子集或父集。 然而，当名字空间下存在多个 PDB 时，用户必须小心，保证 PDB 的选择算符之间不重叠。