Project challenges / verified progress
Beacon: give it somewhere to live

The engineering notebook

Let the cluster ask

How should Kubernetes decide whether Beacon is alive, ready and finished starting?

Loading statusStage 6 of 10

  • Workspace not ready
  • Agent not ready
Focus25:00
A small focus ritual

0 focus sessions completed. Every fourth session offers a longer break. Start each phase when you are ready.

Study time never unlocks verified lesson progress.

Loading...

Loading verified progress...

Loading GitHub account...
Phase 2 — Define the runtime contract

Step 01 of 06

Learn the concept

Beacon asks the internet whether sites are healthy. Now the cluster asks Beacon the same kind of question. The punchline is that the cluster's question can kill the process, so it had better be a narrow one.

ONE PROBE, THREE JOBSHTTP probecluster asks BeaconStartupprotects slow bootgates othersReadinesscontrols trafficno restartLivenessrestarts stuck poduse sparingly
A Kubernetes probe is a prober. It asks a small question on a schedule and acts on the answer. The dangerous part is choosing the wrong question for the job.
Step 01

The ideas this is made of

A probe is the same idea as Course 1

Course 1 built a prober: ask an endpoint a question, classify the answer and record timing. Kubernetes probes do that inside the cluster. The kubelet asks /healthz or /readyz on a schedule. It does not understand your business; it only sees success, failure and thresholds. A probe is a small monitor with authority to change routing or restart a container.

Readiness removes traffic without killing the process

A readiness probe answers: should this Pod receive Service traffic now? If it fails, Kubernetes removes the Pod from Service endpoints. The container keeps running. That is perfect for dependency warmups, migrations or backpressure. It is not a punishment; it is a traffic gate. A failing readiness probe often appears as empty or reduced EndpointSlices.

Liveness restarts the container, so make it narrow

A liveness probe answers: is this process wedged beyond self-repair? If it fails enough times, kubelet restarts the container. A catastrophic beginner mistake is checking a database or external API in liveness. When the dependency fails, Kubernetes kills every otherwise healthy app instance, creating a restart storm on top of the outage.

Startup gives slow programs a grace period

A startup probe disables liveness and readiness checks until startup succeeds or its failure threshold is exhausted. It is useful for programs that need migrations, cache loading or slow first boot. Without it, an impatient liveness probe can kill the process before it has ever had a fair chance to become alive.

A shop sign is readiness
lights on: process alive
front door open: ready
safe jammed shut: liveness failure
coffee supplier late: not liveness

A late supplier should not make the owner demolish the shop. That is what a liveness probe against a dependency does.

Liveness, readiness and startup

ProbeFailure actionGood question

startup

Keep waiting, then kill

Has boot completed?

readiness

Remove from endpoints

Can I serve now?

liveness

Restart container

Is the process stuck?

dependency check

Usually readiness

Can required dependency be used?

external internet

Never liveness

Outages are not deadlocks

What these are called on the job

  • kubelet — The node agent that runs containers and executes probes for Pods on that node.

  • Liveness probe — A check whose repeated failure restarts the container.

  • Readiness probe — A check whose failure removes the Pod from Service endpoints.

  • Startup probe — A check that delays other probes while a container is still starting.