Practical technology learning
Kubernetes Probes: Separate Readiness, Liveness and Startup Questions
Treat health checks as application decisions before treating them as configuration fields. Plan a small disposable-cluster experiment with a controllable sample application and record what each probe is intended to establish. This guide proposes a learning exercise; it does not claim that any production cluster was tested or changed.
Write the three questions first
Describe a normal state, a temporary not-ready state and an unrecoverable application state in plain language. Ask what should happen to traffic eligibility and whether restarting the container would help. Keep these two decisions separate in the review sheet.
Readiness controls whether a container is ready to participate in the relevant Service endpoints. Liveness failures can lead the kubelet to restart the affected container after the configured conditions are met. They are not interchangeable ways to declare that something is unhealthy.
Make the application state observable
Choose a small sample application that can deliberately expose different health responses in a local learning environment. Identify the cluster context and namespace before testing. Keep credentials, real customer traffic and production dependencies outside this disposable experiment.
Record the application’s state alongside the probe observation. A returned success response only proves what the endpoint actually checks. If the endpoint always says healthy, adding a probe around it does not create useful application insight.
Test readiness without assuming a restart
Make the sample temporarily not ready while leaving its process running. Observe readiness and the relevant endpoint eligibility, and inspect restart count separately. Compare those observations with your written expectation rather than interpreting a Pod phase as the whole result.
Restore the ready state and observe recovery. Keep the test focused on the chosen Service and its endpoint behaviour; do not generalise it to every possible direct network path into a Pod.
Plan liveness and startup deliberately
Use a separate controlled failure for liveness and observe the restart count, events and recovery after the configured failure threshold. Do not adopt a very aggressive timing value simply because it makes the demonstration happen quickly.
If a startup probe is configured, liveness and readiness probes wait until it succeeds. Measure the sample’s startup needs and record why each timing choice is suitable. A shared dependency failure should not automatically become a liveness condition that repeatedly restarts otherwise useful containers.
Keep the evidence separate
- Application state and probe results are recorded together.
- Traffic eligibility is checked independently of restart count.
- Readiness failure is not described as a restart instruction.
- Thresholds and delays have an explained basis.
- Cleanup affects only the disposable exercise resources.
Use the plan in a learning discussion
Bring the expected-state sheet to a Kubernetes discussion before writing a larger deployment. Mango Engineers’ Kubernetes course includes health-check and operations foundations; ask about Docker prerequisites, the current lab environment and practical scope.