<p>we have an app in production which need to be highly available (100%),so we did the following:</p>
<ol>
<li>We configure 3 instance as HA but then the node died</li>
<li>We configure anti-affinity (to run on differents nodes) but some update done on the nodes and we were unavailable(evicted) for some min.</li>
<li>Now we consider to add pod disruption Budget
<a href="https://kubernetes.io/docs/concepts/workloads/pods/disruptions/" rel="nofollow noreferrer">https://kubernetes.io/docs/concepts/workloads/pods/disruptions/</a></li>
</ol>
<p>My question are:</p>
<ol>
<li>How the affinity works with pod disruption Budget, could be any collusion ? or this is redundant configs ?</li>
<li>is there any other configuration which I need to add to make sure that my pods <strong>run always</strong> (as much as possible )</li>
</ol>

<blockquote>
<p>How the affinity works with pod disruption Budget, could be any collusion ? or this is redundant configs ?</p>
</blockquote>
<p><a href="https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity" rel="nofollow noreferrer">Affinity and Anti-affinity</a> is about <strong>where</strong> your Pod is scheduled, e.g. so that two replicas of the same app is not scheduled to the same node. <a href="https://kubernetes.io/docs/concepts/workloads/pods/disruptions/#pod-disruption-budgets" rel="nofollow noreferrer">Pod Disruption Budgets</a> is about to increase availability when using <em>voluntary disruption</em> e.g. maintenance. They are both related to making better availability for your app - but not related to eachother.</p>
<blockquote>
<p>Is there any other configuration which I need to add to make sure that my pods run always (as much as possible)</p>
</blockquote>
<p>Things will fail. What you need to do is to embrace <strong>distributed systems</strong> and make all your workload a distributed system, e.g. with multiple instances to remove <em>single point of failure</em>. This is done differently for <em>stateless</em> (e.g. <a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/" rel="nofollow noreferrer">Deployment</a>) and <em>stateful</em> (e.g. <a href="https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/" rel="nofollow noreferrer">StatefulSet</a>) workload. What's important for you is that your <strong>app</strong> is available at much as possible, but individual instances (e.g. Pods) can fail, almost without that any user notice it.</p>
<blockquote>
<p>We configure 3 instance as HA but then the node died</p>
</blockquote>
<p>Things will always fail. E.g. a physical node may crash. You need to design your apps so that it can tolerate some failures.</p>
<p>If you use a cloud provider, you should use <em>regional clusters</em> that uses three independent <em>Availability Zones</em> and you need to spread your workload so that it runs in more than one <em>Availability Zone</em> - in this way, your app can tolerate that a whole <em>Availability Zone</em> is <em>down</em> without affecting your users.</p>
