<p>I was wondering what added value gives the PodDisruptionBudget.</p>
<p>As far as I understand, PodDisruptionBudget promises that a certain amount of nodes will always remain in the cluster while there are 2 options to decide how: minAvailable / maxUnavailable.</p>
<p>Now, when I define ReplicaSet I define how many replicas I want. So if for example I define 2, there won't be less than 2 replicas. Then what gives the PodDisruptionBudget?</p>

<p><code>PodDisruptionBudget</code> helps in ensuring zero downtime for an application which <code>ReplicaSet</code> can't guarantee.</p>
<p>The <a href="https://medium.com/@dwdraju/poddisruptionbudget-a-key-for-zero-downtime-c478d056e373" rel="noreferrer">following post</a> explains with an example how <code>PodDisruptionBudget</code> can be useful in achieving zero downtime for an application:</p>
<p>Quoting the post, the node upgrade is a normal scenario as described in:</p>
<blockquote>
<p>Let’s consider a scenario, we need to upgrade version of node or
update the spec often. Cluster downscaling is also a normal condition.
In these cases, the pods running on the to-be-deleted nodes needs to
be drained.</p>
</blockquote>
<p><code>kubectl drain</code> is performed on one of the nodes for the upgrade:</p>
<blockquote>
<p>We need to remove node1 from the pool which we cannot do it by
detaching instantly as that will lead to termination of all the pods
running in there which can get services down. First step before
detaching node is to make the node unscheduled.</p>
</blockquote>
<p>Running <code>kubectl get pods -w</code> will show the pods running on the node get in termination state which leads to a downtime:</p>
<blockquote>
<p>If you quickly check the pods with kubectl get pods , it will
terminate all the running pods instantly which were scheduled on node1
. This could lead a downtime! If you are running few number of pods
and all of them are scheduled on same node, it will take some time for
the pods to be scheduled on other node.</p>
</blockquote>
<p><code>PodDisruptionBudget</code> with <code>minAvailable</code> are useful in such scenarios to achieve zero downtime. <code>Replicaset</code> will only ensure that the <code>replicas</code> number of pods will be
created on other nodes during the process.</p>
<p>If you just have a <code>Replicaset</code> with one replica and no <code>PodDisruptionBudget</code> specified, the pod will be terminated and a new pod will be created on other nodes. This is where <code>PDB</code>s provide the added advantage over the <code>Replicaset</code>.</p>
<blockquote>
<p>For the PodDisruptionBudget to work, there must be at least 2 pods
running for a label selector otherwise, the node cannot be drained
gracefully and it will be evicted forcefully when grace time ends.</p>
</blockquote>
