Separate AI worker readiness from probe-driven restart decisions

Choose the consequence before naming the health endpoint

A fictional summary service W-A runs as one trusted application container in an ordinary Pod. It needs time to initialize, can temporarily lose an external model dependency, and can also suffer a genuine local inability to make progress. Calling all three states unhealthy hides the action an operator is asking Kubernetes to take.

This worksheet selects fixed HTTP GET handlers for startup, readiness and liveness, with Pod restartPolicy Always and no container-level restart override. Sidecars, init containers, alternative probe mechanisms, rollout controllers and meshes are excluded. The reviewed official pages show v1.37 navigation; their modified dates are 30 June and 27 July 2026. No actual cluster or installed component was inspected.

Supported kubelet behavior, effective configuration, handler implementation, resource bounds and current request rights are unimplemented prerequisites. Unknown evidence blocks the conditional positive. All eight cards are PROPOSED_UNRUN: no Pod, HTTP request, probe, timer, process or restart fixture was exercised.

Use three questions instead of one shared failure signal

The Pod lifecycle reference says a configured startup probe suppresses liveness and readiness until it succeeds. Startup failure subjects the killed container to restart policy. Liveness failure beyond configured tolerance causes a restart; readiness instead concerns serving eligibility. The selected Always policy restarts an application container after termination.

For W-A, propose three independently reviewed meanings: startup means the admitted local initialization has completed; liveness means the local service satisfies its defined survival criterion; readiness means this instance can serve the declared request class under current operating conditions. These are application choices, not definitions automatically inferred by Kubernetes from a status code.

A temporary provider outage therefore needs its own classification. If W-A is locally responsive but cannot serve the required summaries, the proposed readiness decision can become false while its local survival criterion remains true. Do not make every dependency failure a liveness failure merely because restarting is available. A different service that can usefully serve partial functionality needs a different readiness contract.

Make the health handler report state rather than create work

The HTTP probe guide treats response codes from 200 through 399 as success. A pleasant response body or the presence of the word healthy does not define the application condition. For this narrower proposed handler, choose explicit success or failure responses from trusted local state; reject a design that relies on redirects or a generic login response as its health signal.

The handler must not create a summary, submit a customer prompt, reserve model usage, refresh a business workflow or send a message. It also must not perform an unbounded provider test on every probe. Review its complete dependency graph: a small wrapper can still call a shared service method with side effects.

If readiness depends on dependency evidence, define how that evidence is obtained, bounded and considered stale outside this handler. That monitoring design is not implemented here. A cached positive flag without a supported freshness rule cannot establish present serving capability; an unknown flag should produce the declared unavailable state rather than guess success.

Record initialization and steady-state policies separately

The startup guidance supports allowing initialization time before ordinary liveness takes over. W-A needs a reviewed startup allowance based on its actual initialization path, not a copied tutorial number. The actual failure tolerance, probe schedule and handler limits remain deployment requirements; this worksheet recommends no timing values.

Invent policy sheet P-A with worker/build revision, the three fixed handler identities, each condition, supported response mapping, failure policy and intended consequence. Record evidence for successful startup separately from later readiness. After startup, a local failure and a remote dependency problem must still select the appropriate condition rather than collapse into one permanent initialization state.

The conditional positive is useful ordinary service: local initialization completes, bounded local responses match their criteria, and the declared serving conditions hold. This makes P-A eligible for independently authorized deployment review. It reports no running Pod, successful probe, accepted request or completed model task.

Walk eight inert condition-to-action cards

These cards change one declared condition at a time. Retain minimized policy, worker and disposition references rather than prompts, provider credentials or detailed internal dependency responses in health output or routine evidence.

Keep readiness and restart smaller than job completion

A readiness transition is not proof that existing connections drained or every path stopped sending requests. A restart is not a transaction rollback, a cancellation acknowledgement or evidence that an external model stopped consuming usage. Actual application state must settle those questions; this worksheet supplies no Service-routing, draining or recovery implementation.

The outage playbook still governs provider-attempt classification, and the budget guide still preserves uncertain charges. Do not let a fresh process clear those records or automatically repeat business effects.

No Kubernetes API, command, manifest, handler, cluster, runtime or model operation was performed. Boundary is prelaunch and provides no shipped Kubernetes health controller or job-recovery service. Its synthetic policy evidence concerns different behavior.