Why does Openshift scale up old deployment before rolling deployment

Question

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 "old" 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.

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?

OpenShift Master: v3.11.200
Kubernetes Master: v1.11.0+d4cacc0
OpenShift Web Console: 3.11.200-1-8a53b1d

From our Openshift template:

- apiVersion: v1
  kind: DeploymentConfig
  spec:
    replicas: 2
    strategy:
      type: Rolling

Are you sure that access are routed to the new pods while they are created. OCP (and k8s) will route the traffic rom teh service only when the pods with the new version are up and running. If you want to shutdown the old app and deploy the new onw, use a strategy of type "recreate" — titou10

acid_fuji acid_fuji · Accepted Answer · 2020-08-03T10:48:08

This is expected behavior when using RollingUpdate 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 zero-downtime as requested in the manifest.

It scales up to 2, because if not specified maxSurge defaults to 25%. It means that there can be at most 25% more pod instances than the desired count during an update.

If you want to ensure that this won't be scaled you might change the strategy to Recreate. 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.

Here`s a good document that describes rolling update strategy. It is worth also checking official kubernetes documentation about deployments.

Why does Openshift scale up old deployment before rolling deployment

1 Answers