<p>Imagine in a Master-Node-Node setup where you deploy a service with pod anti-affinity on the Nodes: An update of the Deployment will cause another pod being created but the scheduler not being able to schedule, because both Nodes have the anti-affinity.</p>

<p><strong>Q:</strong> How could one more flexibly set the anti-affinity to allow the update?</p>

<pre><code>affinity:
   podAntiAffinity:
     requiredDuringSchedulingIgnoredDuringExecution:
     - labelSelector:
         matchExpressions:
         - key: app
           operator: In
           values:
           - api
     topologyKey: kubernetes.io/hostname
</code></pre>

<p>With an error </p>

<pre><code>No nodes are available that match all of the following predicates:: MatchInterPodAffinity (2), PodToleratesNodeTaints (1).
</code></pre>

<p>Look at <a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#max-surge" rel="noreferrer">Max Surge</a></p>

<p>If you set Max Surge = 0, you are telling Kubernetes that you won't allow it to create more pods than the number of replicas you have setup for the deployment. This basically  forces Kubernetes to remove a pod before starting a new one, and thereby making room for the new pod first, getting you around the podAntiAffinity issue. I've utilized this mechanism myself, with great success.</p>

<p><strong>Config example</strong></p>

<pre><code>apiVersion: extensions/v1beta1
kind: Deployment
    ...
spec:
  replicas: &lt;any number larger than 1&gt;
    ...
  strategy:
    rollingUpdate:
      maxSurge: 0
      maxUnavailable: 1
    type: RollingUpdate
    ...
  template:
    ...
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - api
          topologyKey: kubernetes.io/hostname
</code></pre>

<p><strong>Warning:</strong> Don't do this if you only have one replica, as it will cause downtime because the only pod will be removed before a new one is added. If you have a huge number of replicas, which will make deployments slow because Kubernetes can only upgrade 1 pod at at a time, you can crank up <em>maxUnavailable</em> to enable Kubernetes to remove a higher number of pods at a time.</p>
