Cloud & Systems
Infrastructure from packets to platforms.
1200 learning records across 10 categories. Choose a level and build a plan that fits your next goal.
Your subject plan
Explore and verify
Every lesson opens on its own route with its available explanation, lab, practice, and evidence views. Published depth varies; a plan does not imply research mastery or verified completion.
AUTHORED STUDY COMPANION / 3.4
Distinguish readiness from liveness during a failure
Prerequisites. Pods, service endpoints, health checks and application dependencies.
A startup probe can give a slow application time to initialize before liveness and readiness checks take effect. Once started, readiness answers whether the container should receive normal service traffic; liveness answers whether the container is considered unhealthy enough for a restart under its configured policy. A pod can be running and live while unready.
The companion models one decision instant with three booleans. Started=true, ready=false, live=true removes normal endpoint eligibility without requesting a restart. Started=true, live=false requests a restart in this simplified model. Started=false suppresses the other decisions. The fixture omits failure thresholds, periods, initial delays, backoff, controller latency and service options, so it is not a Kubernetes emulator.
For a dependency outage, an indiscriminate liveness failure can cause restart loops without fixing the dependency. Investigate events, application responses and endpoint membership before changing probes. The downloadable manifest is an inspection fixture with no credentials; applying it to a real cluster requires a separate environment and image choice. No cluster deployment or recovery test is claimed by this notebook.
| Element | Model | Interpretation |
|---|---|---|
| Startup | Initialization complete? | Gates subsequent checks |
| Readiness | Ready to receive traffic? | Endpoint eligibility |
| Liveness | Restart warranted? | Container recovery action |
Predict, run, compare
The default case is started but unready and live: eligible_endpoint=false, restart_requested=false. Flip only live to false and observe the independent restart decision.
Download executable notebooks and source Inspect source ↗
Open kubernetes.ipynb in the package. Run cells in order, compare with the reference, then change the stated input. Restart the kernel to reset.
Computed reference result — local CPU fixture
{
"startup_complete": true,
"readiness_evaluated": true,
"liveness_evaluated": true,
"eligible_endpoint": false,
"restart_requested": false,
"recovery_plan": [
"Inspect pod events and probe results",
"Check application dependencies",
"Fix or roll back the failed change",
"Verify endpoint membership and application response"
],
"scope": "one probe decision instant; thresholds, delays, backoff, network policy and controller timing omitted"
}This is the recorded result of the included code under the package environment. It is not a live service or device measurement.
Extend the experiment
Write a dependency-outage timeline. Predict pod phase, readiness, service endpoints and restart count separately, then identify the read-only observations needed to test each prediction.
Check your reasoning: A live but unready container necessarily needs:
- An immediate restart — Readiness alone does not request a restart.
- Removal from normal ready endpoints, under the stated service model — Correct. Traffic eligibility and process health are distinct.
- Deletion of its persistent volume — Readiness does not authorize destructive storage changes.
This is an explained self-check, not a certification of mastery.
Claim-specific sources
Reviewed 2026-10-02: this worked example and its explicit assumptions. Source links and notebook results do not establish production or hardware validation.