Imagine you have an application pod running in a Kubernetes environment at version v1. You've developed v2, and now you want to deploy it. But how should you approach this? Do you delete and take down every pod, creating a new deployment with the updated version?
However, this method would cause downtime, and that's not something we want, right?
Kubernetes offers deployment strategies to address this issue:
Within your Deployment manifest, spec.strategy.type offers two values:
RollingUpdate: This strategy gradually adds new pods while gradually terminating old ones.
Recreate: All old pods are terminated before any new ones are added.
Let's delve deeper into the Rolling Update strategy:
Kubernetes' Rolling Update strategy involves gradually introducing new pods while gradually phasing out the old ones. But how does Kubernetes determine the number of pods to terminate and add during this process?
To resolve this issue, we have two additional configurable options:
maxSurge: This value represents the number of pods that can exceed the desired pod count during an update.
maxUnavailable: This value represents the number of pods that can be unavailable during the update process.
These values can be specified as integers or percentages. When using integers, they denote the count of pods, whereas percentages indicate the proportion of pods concerning the desired count.
For instance: Suppose the desired pod count is 10. During the update, there can be a maximum of 12 pods (10 desired + 2 maxSurge) available, indicating the number of pods created simultaneously. Conversely, a minimum of 8 pods (10 desired - 2 maxUnavailable) might be available during the update, representing the number of pods that can be deleted at a time.
Now, let's discuss the Recreate strategy:
The Recreate strategy involves deleting all available v1 version pods and then creating v2 version pods. This method results in downtime until the new pods are created.
Thanks for reading,