A rolling update can stay within its availability settings and still put pressure on a cluster. The useful planning question is therefore broader than how many replacement Pods Kubernetes may start: what else will consume resources while those replacements become ready?
The distinction matters when a service has a slow startup, a long shutdown, or little spare capacity. The following is a design walkthrough, not a report of a measured production incident.
Separate availability from resource consumption
The Kubernetes Deployment documentation defines maxUnavailable as the allowed unavailability during a rolling update and maxSurge as additional Pods above the desired count. It also warns that terminating Pods can consume resources beyond replicas + maxSurge until their termination grace period expires. A surge setting is consequently insufficient as a physical resource budget.
Consider a hypothetical service whose old workers drain long-running requests while replacements initialize. Sketch three groups on a planning sheet: workers serving traffic, replacements preparing to serve, and old workers shutting down. For each group, record the resource requests, observed consumption, and expected duration. The purpose is to expose overlap, not to derive a universal safe replica count.
This gives an operator two separate questions to answer. Is enough usable serving capacity available? Can the infrastructure accommodate the temporary overlap? A favorable answer to either question does not establish the other. Test both under conditions representative of the application.
Give each probe a specific job
The probe concepts documentation distinguishes readiness, liveness, and startup checks. Failed readiness checks remove a Pod from matching Service endpoints; failed liveness checks can restart the container. A configured startup probe prevents liveness and readiness probes from running until it succeeds. Those outcomes are different operational decisions.
For the hypothetical service, write down what each endpoint actually demonstrates. Can it accept useful work? Is the process stuck in a state that restarting can repair? Is initialization still legitimately in progress? Avoid using an undifferentiated dependency check to answer all three questions without examining its failure consequences.
As a design exercise, trace a shared dependency slowdown. If every instance fails the same check simultaneously, what happens to traffic and restart activity? This exercise does not prescribe a universal probe implementation. It forces the team to examine whether the configured response helps the particular failure or adds more work during recovery.
Measure the transition, not just the steady state
The probe configuration guide describes allowing sufficient startup time with failureThreshold and periodSeconds. Use those documented controls with measurements of the actual initialization path; a copied value from another service is only a starting hypothesis.
In a controlled test environment, observe a replacement from scheduling through initialization, readiness, useful work, and eventual shutdown. Repeat under a representative workload. Record the sequence alongside resource consumption and application errors. A green readiness check is evidence about the configured check; application measurements are still needed to assess whether the rollout meets the service’s goals.
Before a production change, agree on explicit pause criteria, who evaluates them, and how to inspect a stalled rollout. Separate configuration mistakes from capacity shortages and application regressions. Changing several controls at once makes that diagnosis harder.
A practical review checklist
- Document availability settings and temporary resource overlap separately.
- Explain the intended outcome of each probe failure.
- Measure startup and shutdown under a representative load.
- Check whether a shared dependency failure amplifies restarts.
- Define pause criteria before starting the rollout.
These checks turn rollout settings into testable assumptions. They do not promise a particular latency improvement or eliminate failure. Their value is making the application’s transition behavior visible before availability controls are mistaken for a complete capacity plan.