PodDisruptionBudget简介

PodDisruptionBudget 这个控制器直译就是Pod干扰预算，这个控制器主要是通过设置应用 Pod 处于正常状态的最低个数或最低百分比，这样可以保证在主动销毁 Pod 的时候，不会销毁太多的 Pod 导致业务异常中断，从而提高业务的可用性

Deployment中的maxUnavailable和RS Controller不是也有一个保持Pod的最低个数或者百分比的设置，其实它们并不能给你保证集群中始终有几个副本的，只是让实际副本数跟你的期望副本数尽快的一致，但这个过程中的副本数量就不管了。所以这个时候就可以考虑使用PDB，对那些Voluntary Disruption做好Budgets

Involuntary AND Voluntary Disruption

刚说了对Voluntary Disruption的情况，可以使用PDB做预算。现在先来看看常见的Involuntary Disruption

服务器硬件故障或者内核崩溃导致节点宕了
如果节点是 KVM，Xen 虚拟机，虚拟机被删了或者 KVM，Xen 崩了
集群网络脑裂
某个节点因为不合理的超配导致出现计算资源不足时，触发了kubelet eviction

一看就是Kubernetes不可控的情况，这些情况下不适用于PDB

那么常见的Voluntary Disruption都有哪些

删除Deployment，RC，StatefulSet控制器
更新了 Pod 模版，触发 Pod 滚动更新
批量删除Pod
清空节点
下线一个节点

Disruption Budget

Disruption归根结底可以就是删除Pod，上面的各种Voluntary Disruption情况，最终的操作都是删除Pod

Budget就很好理解了，就像你平时花钱，有多少预算买多少钱的东西，这里的预算也大体一致，不过这里的预算是你可以删除Pod的数量，比如你允许Zookeeper最多宕机30%的Pod，那么就会根据你当前的状态和你的预算来计算可以中断（删除）多少Pod

设置PDB

下面来实战一下，其实PDB关键的设置项就3个

.spec.selector用于指定其所作用的Pod集合，该字段为必需字段
.spec.minAvailable表示驱逐后仍须保证可用的Pod数量。该字段可以是百分比，也可以是绝对值
.spec.maxUnavailable表示驱逐后允许不可用的Pod的最大数量。该字段可以是百分比，也可以是绝对值

注意：.spec.minAvailable和.spec.maxUnavailable是互斥的，只能存在一个，如果即没有设置.spec.minAvailable也没有设置.spec.maxUnavailable的话，那么会默认设置.spec.minAvailable为1

下面以Zookeeper为例，设置一个 PDB，具体的yaml文件如下

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: zookeeper

由于Zookeeper为了可用性，至少要有2个节点正常才能保障可用，所以我们设置minAvailable为2，当然也可以设置maxUnavailable为1

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app: zookeeper

使用注意事项

如果只使用与内置的应用控制器（Deployment、ReplicationController、ReplicaSet 和 StatefulSet）对应的 PDB，那么你正常按照上面的说明配置即可。如果你使用了例如Operator的其他控制器，那么设置时就要注意以下2点：

只能配置 .spec.minAvailable,不能使用 maxUnavailable
.spec.minAvailable 只能为整型值，不能是百分比

Deployment中maxUnavailable与PDB的maxUnavailable

如果设置一个Deployment中.spec.strategy.rollingUpdate.maxUnavailable等于一个值，然后为这个Deployment设置一个PDB ，其中.spec.maxUnavailable设置一个不同的值，那么谁的优先级高，这就要分2种情况来看：

如果是滚动更新的操作，那么Deployment中.spec.strategy.rollingUpdate.maxUnavailable的是值会生效，即使PDB的.spec.maxUnavailable设置的值更小

如果是Eviction的情况，那么PDB的.spec.maxUnavailable的值将优先级更高，即使Deployment中.spec.strategy.rollingUpdate.maxUnavailable的值设置的更小

这种逻辑很显然更符合Kubernetes的工作原理，Deployment不会去读取PDB的字段的，同样的PDB也不会去读取Deployment的字段。2个独立的控制器，所以没有关联，只是字段名一样而已