Run a rolling update that drops requests, then one that does not
Task
Perform the same rolling update twice: once without a readiness probe and once with. The first drops requests and the second does not, and the difference is visible in a continuous client's error count.
Steps
- Deploy the application with four replicas and NO readiness probe, behind a service. Start a client making continuous requests and counting failures into
lab/rollout.csv. - Trigger a rolling update by changing the image tag. Record the failure count during the rollout.
- Add a readiness probe that only passes once the application is truly serving. Roll out again and record the failure count.
- Now set maxUnavailable high -- more than half the replicas -- and roll out a third time. Record what happens to capacity and latency even with the probe in place.
- Write in
lab/rollout.mdthe three configurations, their failure counts, and the one-line rule each demonstrates.
Verify
awk -F, 'NR>1 && NF>=2 {n++} END {print n" rollout record(s)"}' lab/rollout.csv
grep -Eci 'readiness' lab/rollout.md
grep -Eci 'maxunavailable|unavailable' lab/rollout.md
grep -Ec '[0-9]+ (failure|error)' lab/rollout.md
Three rollouts recorded with different failure counts. If the first rollout dropped nothing, the application became ready too quickly -- add a startup delay so the window is observable.
This is an independent study companion for CompTIA Cloud+ CV0-004 and is not produced by or endorsed by CompTIA.