<h1>Problem</h1>
<p>I've got a Kubernetes deployment of 20 replicas that needs runs long celery tasks. We deploy frequently to our cluster (at most ~every 10 mins). I set a long termination period of 3 hours for my pods so the tasks don't get interrupted. The problem is, on every deploy Kubernetes tries to create an additional 20 pods. How do I keep Kubernetes from scheduling additional pods before the existing ones are terminated?</p>
<h1>Release</h1>
<p>My release is a GitHub action that does a helm upgrade and swaps in the new image tag that was just built.</p>
<pre><code>helm upgrade --kube-context SK2 --install 
-f ./kube/helm/p1/values_SK2.yaml 
-n $REPOSITORY_NAME 
--set image.tag=$GIT_COMMIT 
$REPOSITORY_NAME 
./kube/helm/p1 
--atomic --debug --history-max=100 --timeout 6m
</code></pre>
<h1>Attempt 1</h1>
<p>I tried to set a RollingUpdate strategy with the maxUnavilable to 20 and the max surge to 1 so that it would only ever create 1 additional pod on the deployments, but not schedule new pods until all the old pods are terminated.</p>
<pre><code>strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 20
      maxSurge: 1
</code></pre>
<h1>Attempt 2</h1>
<p>I've also tried pinning the image to latest instead of updating the image on deploy then changing the deployment's image tag after the helm install.</p>
<pre><code>kubectl --context SK2 -n p1 set image deployment/celery-io-long celery-io-long=stringking/p1:$GIT_COMMIT
</code></pre>
<p>Both of these techniques have the end result of creating a new batch of 20 pods on deployment before the old ones are terminated. What am I doing wrong here?</p>

MikeSchem
<p>setting the maxUnavailable value to 20, means that 20 will be unavailable simultaneously during the rolling update and will spin up new pods with the new deployment.</p>
<p>You should set its value to:</p>
<pre><code>maxUnavailable: 1 
maxSurge: 1
</code></pre>
<p>This ensures that only 1 out of the 20 existing pods will be terminated once the rolling update has started and doesn't schedule additional pods until the existing ones are terminated.</p>
