Middle · Docker and Kubernetes
Startup, readiness and liveness probes
Why are three Kubernetes probes different?
Try explaining this aloud before opening the answer. State your assumptions and trace a boundary case.
Reveal a strong answer
A startup probe allows a slow application to initialize before other probes take over. Readiness reports whether the Pod should receive service traffic. Liveness signals a stuck process that should be restarted.
A shared database outage usually should not make every instance restart continuously. Define readiness/degraded behavior from the service contract and keep probe work cheap and bounded.
A probe success is only a point-in-time observation, not a guarantee for the next request. Include timeouts, thresholds and resource headroom, then verify rollout behavior under slow startup and dependency failure.
Common trap
Using the same deep dependency check for all probes can amplify an external outage into a restart storm.
Try it
Your process is responsive but cannot reach MongoDB. Which probe should necessarily fail?
Worked solution
Liveness need not fail: restarting a healthy process may not repair the database. Readiness depends on whether the service can fulfill its traffic contract. Startup only concerns initialization. Document the policy rather than copying one endpoint into every probe.
Change the constraint
When is a separate lightweight local progress check useful for worker liveness?
How did you do?
Self-assessment, not a compiler pass or interview score. Explain the reasoning unaided before marking understood.
Not marked. Progress stays on this browser, separate from course completion.
Primary references
Checked 2026-10-20. Use documentation for your pinned runtime, driver and tool version.