<p>If I have the following Kubernetes objects:</p>

<ul>
<li><code>Deployment</code> with <code>rollingUpdate.maxUnavailable</code> set to <code>1</code>.</li>
<li><code>PodDisruptionBudget</code> with <code>maxUnavailable</code> set to <code>1</code>.</li>
<li><code>HorizontalPodAutoscaler</code> setup to allow auto scaling.</li>
<li>Cluster auto-scaling is enabled.</li>
</ul>

<p>If the cluster was under load and is in the middle of scaling up, what happens:</p>

<ol>
<li>During a rolling update? Do the new <code>Pod</code>'s added due to the scale up use the new version of the <code>Pod</code>?</li>
<li>When a node needs to be restarted or replaced? Does the <code>PodDisruptionBudget</code> stop the restart completely? Does the <code>HorizontalPodAutoscaler</code> to scale up the number of nodes before taking down another node?</li>
<li>When the <code>Pod</code> affinity is set to avoid placing two <code>Pod</code>'s from the same <code>Deployment</code> on the same node.</li>
</ol>

<ol>
<li>As in <a href="https://kubernetes.io/docs/concepts/workloads/pods/disruptions/#how-disruption-budgets-work" rel="nofollow noreferrer">documentation</a>:</li>
</ol>

<blockquote>
  <p>Pods which are deleted or unavailable due to a rolling upgrade to an application do count against the disruption budget, but controllers (like deployment and stateful-set) are not limited by PDBs when doing rolling upgrades – the handling of failures during application updates is configured in the controller spec.</p>
</blockquote>

<p>So it partially depends on the controller configuration and implementation. I believe new pods added by the autoscaler will use the new version of the Pod, because that's the version present in deployments definition at that point.</p>

<ol start="2">
<li><p>That depends on the way you execute the node restart. If you just cut the power, nothing can be done ;) If you execute proper <code>drain</code> before shutting the node down, then the <code>PodDisruptionBudget</code> will be taken into account and the draining procedure won't violate it. The disruption budget is respected by the Eviction API, but can be violated with low level operations like manual pod deletion. It is more like a suggestion, that some APIs respect, than a force limit that is enforced by whole Kubernetes.</p></li>
<li><p>According to the <a href="https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity" rel="nofollow noreferrer">official documentation</a> if the affinity is set to be a "soft" one, the pods will be scheduled on the same node anyway. If it's "hard", then the deployment will get stuck, not being able to schedule required amount of pods. Rolling update will still be possible, but the HPA won't be able to grow the pod pool anymore.</p></li>
</ol>
