<p>In my team, we sometimes scale down to just one pod in Openshift to make testing easier. If we then do a rolling update with the desired replica count set to 2, Openshift scales up to two pods before performing a rolling deploy. It is a nuisance, because the new &quot;old&quot; pod can start things that we don't expect to be started before the new deployment starts, and so we have to remember to take down the one pod before the new deploy.</p>
<p>Is there a way to stop the old deployment from scaling up to the desired replica count while the new deployment is scaled up to the desired replica count? Also, why does it work this way?</p>
<ul>
<li>OpenShift Master:
v3.11.200</li>
<li>Kubernetes Master:
v1.11.0+d4cacc0</li>
<li>OpenShift Web Console:
3.11.200-1-8a53b1d</li>
</ul>
<p>From our Openshift template:</p>
<pre><code>- apiVersion: v1
  kind: DeploymentConfig
  spec:
    replicas: 2
    strategy:
      type: Rolling
</code></pre>

Programmer Trond
<p>This is expected behavior when using <code>RollingUpdate</code> strategy. It removes old pods one by one, while adding new ones at the same time, keeping the application available throughout the whole process, and ensuring there’s no drop in its capacity to handle requests. Since you have only one pod, Kubernetes scales the deployment to keep the strategy and <code>zero-downtime</code> as requested in the manifest.</p>
<p>It scales up to 2, because if not specified <code>maxSurge</code> defaults to 25%. It means that there can be at most 25% more pod instances than the desired count during an update.</p>
<p>If you want to ensure that this won't be scaled you might change the strategy to <code>Recreate</code>. This will cause all old pods to be deleted before the new ones are created. Use this strategy when your application doesn’t support running multiple versions in parallel and requires the old version to be stopped completely before the new one is started. However please note that, this strategy does involve a short period of time when your app becomes completely unavailable.</p>
<p>Here`s a good <a href="https://blog.sebastian-daschner.com/entries/zero-downtime-updates-kubernetes#:%7E:text=Per%20default,%20Kubernetes%20deployments%20roll,time%20while%20performing%20the%20updates." rel="nofollow noreferrer">document</a>  that describes rolling update strategy. It is worth also checking official kubernetes <a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/" rel="nofollow noreferrer">documentation</a> about deployments.</p>
