Readiness Probes and Rollout Progress
A readiness probe restarts nothing. What it does is decide whether a Pod counts as available - and a Deployment will not retire an old replica until a new one is. That makes readiness the mechanism that turns a broken deploy into a stalled deploy instead of an outage. This shows the stall, proves the Service never degraded, and then adds `minReadySeconds`.
Application Deployment Guide 23 of 44 Intermediate
- Kubernetes1.36.4
- Runtimecontainerd 2.2.6
- CNICalico v3.32.1
- TimeAbout 16 min
- Reviewed23 August 2026
Written against the versions above. `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.
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| CKA1001 | 192.168.0.175 | Ubuntu 26.04 LTS | Control Plane Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE01 | 192.168.0.176 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE02 | 192.168.0.177 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE03 | 192.168.0.178 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
Before you start
- A cluster and kubectl.
- The session creates namespace
ckad-readywith a three-replica Deployment whose readiness depends on a file created by apostStarthook - so the probe can be broken by changing one command.
-
A Deployment that is ready on purpose
-
Break readiness on the new version
-
Nothing restarted, and the Service is intact
-
Roll it back, and add minReadySeconds