Readiness Probes and Rollout Progress

Application Deployment / Guide 23 of 44 / Intermediate

• Kubernetes1.36.4
• Cluster4 nodes
• Runtimecontainerd 2.2.6
• CNICalico v3.32.1
• TimeAbout 16 min

readyReplicas and availableReplicas are different fields. A Pod is ready the moment its probe passes; it is available only after it has been ready for minReadySeconds. With the default of 0 they move together, which is why the distinction is invisible until you set it.

This guide includes

Use this when a rollout has stopped and nothing has actually crashed. This matters because a readiness probe restarts nothing - it withholds the new Pods from the Service, which is exactly what keeps the old version serving while the rollout stalls.

• starting from a Deployment that is Ready on purpose, with a probe you can break deliberately
• breaking readiness on the new version only, and watching the rollout stall
• confirming nothing restarted and the Service endpoints are entirely intact
• rolling back, then adding minReadySeconds and watching it slow the next rollout down

Before you start

• A cluster and kubectl.
• The session creates namespace ckad-ready with a three-replica Deployment whose readiness depends on a file created by a postStart hook - so the probe can be broken by changing one command.

1. 1

   A Deployment that is ready on purpose

2. 2

   Break readiness on the new version

3. 3

   Nothing restarted, and the Service is intact

4. 4

   Roll it back, and add minReadySeconds

Official sources

• Deployment - min ready seconds
• Configure Liveness, Readiness and Startup Probes
• Pod Lifecycle - readiness