Kubernetes readiness: requests, probes and rollout checks

A workload that starts in a test cluster is not yet an operating procedure. Before a Kubernetes service is handed over, the team needs a shared understanding of capacity, traffic readiness and how to recognize a failed rollout. Start with a small number of observable checks and expand them around the application’s behavior.

Set resource requests from evidence

Requests influence scheduling. Limits constrain resource use, but CPU and memory behave differently: CPU can be throttled, while exceeding a memory limit can result in a container being terminated. The Kubernetes resource-management guide explains those distinctions.

Review measurements over representative load, including startup and scheduled work. Record why a request or limit was chosen and what would trigger a review. Avoid treating values copied from another service as capacity evidence. Check pending pods, throttling and memory-related restarts when assessing a proposed change.

Give each probe a clear job

A readiness probe answers whether a container is ready to receive traffic. A liveness probe detects a condition where restarting the container may help. A startup probe gives an application time to initialize before the other probes run. These are different questions, described in the Kubernetes probe documentation.

Choose endpoints and thresholds based on the application’s startup and failure behavior. For example, making liveness depend on a temporarily unavailable external service can cause restarts that do not fix the underlying problem. Test a slow start, a failed dependency and a deliberate readiness failure before relying on the checks in production.

Observe a rollout, not just its exit code

Kubernetes rolling updates use settings such as maxSurge and maxUnavailable to control replacement. Those settings must fit capacity and availability requirements. A deployment progress deadline can report that a rollout has stalled; it does not itself provide a complete application recovery procedure. See the rolling-update guide.

In an authorized environment, begin with read-only inspection. Replace the example namespace and deployment with your workload names:

kubectl -n example get deployment web
kubectl -n example rollout status deployment/web --timeout=120s
kubectl -n example get pods
kubectl -n example get events --sort-by=.metadata.creationTimestamp

If a check fails, inspect the relevant pod status, events and application logs. Do not treat every failure as a reason to retry the deployment immediately. Establish whether the cause is capacity, configuration, image access, a probe or the application itself.

Hand over an operating checklist

Use the walkthrough to confirm that the operating team can:

• Identify the release artifact and workload owner.
• Explain resource requests and the evidence behind them.
• Recognize readiness failure, restarts and a stalled rollout.
• Find the service’s dashboards, logs and escalation contacts.
• Follow a reviewed recovery procedure, including configuration and data dependencies.

Record what was tested and what remains outside the exercise. A successful single-pod test does not demonstrate zone-failure tolerance or recovery of persistent data. Those need separate acceptance criteria.

Explore Kubernetes and platform engineering or read about Kubernetes drift for changes that appear after deployment.