Changes are part of all software life cycles but how do we make sure changes are made safely in Kubernetes (k8s)? We will tackle changes to the application, pods, and the underlying infrastructure by leverage k8s’ RollingUpdate property and Pod Disruption Budgets respectively. We will also take a look into readiness and liveness probes.

Rolling Update

Deployments provide a feature for defining how to perform rolling updates on pods. With RollingUpdate strategy, you define 2 properties, maxSurge and maxUnavailable. MaxSurge defines how many or the percentage of pods that can be spun up above the current pod count during an update. This can be the number you set in your deployment or the current count set by horizontal pod autoscaler (doc). MaxUnavailable specifies how many or the percentage of pods that can be killed during an update.

Example:

In our first deployment (line 10–14), we defined both maxSurge and maxUnavailable as 1. This means during an update 1 new pod is created and 1 old pod is killed until all pods are replaced. Since replica is 10, at most you will see 11 pods and at least you will see 9 pods.

In our second deployment (line 36–40) we defined a percentage. 25% for maxSurge and maxUnavailable. Assuming the current pod count is 10, this means that 4, 10 x 25%, new pods will spin up and 4 old pods will get killed until all pods are replaced. Since replica is 10, at most you will see 14 pods and at least you will see 6 pods.

So when does k8s know when to move on to the next set of pods to update? Readiness and liveness probes.

#software-engineering #devops #kubernetes #software-development #coding