Lesson 8 · Workloads, config & networking

Probes & resources

How Kubernetes knows a Pod is healthy — and how much CPU/memory it's promised and capped at.

Your win: distinguish the three probes (liveness / readiness / startup) — the single most-confused K8s topic in interviews — and explain requests vs limits and what happens when you hit them.

The three probes — different questions, different actions

The kubelet (Lesson 2) runs health checks on each container. There are three, and mixing them up is the classic mistake:¹

Probe	Asks	On failure
startup	"has it finished booting?"	keep waiting; hold off the other two until it passes
readiness	"should it get traffic?"	remove the Pod from Service endpoints (no restart)
liveness	"is it stuck / dead?"	kill & restart the container

The distinction that wins the question Readiness gates traffic; liveness restarts. A failing readiness probe pulls the Pod out of its Service's rotation but leaves it running — perfect for "busy / warming up / dependency down." A failing liveness probe kills the container — reserve it for genuinely unrecoverable states (a deadlock). Get these backwards and a momentarily-busy Pod gets killed in a restart loop. Startup exists so slow-booting apps aren't killed by liveness before they've finished starting.

Requests & limits — the two numbers per resource

request — what the Pod is guaranteed. The scheduler (Lesson 2) uses it to place the Pod on a node with enough room; it's reserved.
limit — the ceiling. Exceed the CPU limit → the container is throttled. Exceed the memory limit → it's OOMKilled (memory can't be throttled).²

Requests drive scheduling and the Quality-of-Service class; limits protect the node from a runaway container. A common production bug: too-low a memory limit → periodic OOMKills that look like random crashes.

Anchor — every service's health check is gRPC All three probes are defined once in the library container template deployments/helm/libs/util/templates/_workload_containers.tpl, and they all shell out to the same binary you met in Course 1:

readinessProbe (:78) → /bin/grpc_health_probe -addr=localhost:{port} (:92)
startupProbe (:103, failureThreshold: 12) → same probe (:117)
livenessProbe (:123) → same probe (:137)

That grpc_health_probe binary was downloaded into the image back in local/Dockerfile.development (Course 1 L2) — it queries the gRPC health service your Go server exposes. Resources come from .Values.resources (:145-146); concrete example backend/tom/values.yaml:53-59 (requests.memory: 128Mi, probes enabled). So health and sizing are per-service values, one shared template.

Kubernetes docs — Probes & managing resources

The three probe types with their failure semantics, and how requests/limits drive scheduling and QoS.

→ kubernetes.io — Probes (how-to: configure probes)
→ kubernetes.io — Resource requests & limits

Check yourself (from memory)

Q1. A failing readiness probe causes Kubernetes to…

Readiness gates traffic (removed from Service endpoints), no restart. Liveness is the one that restarts.

Q2. A container that exceeds its memory limit is…

Memory can't be throttled, so over-limit → OOMKill. CPU over-limit is throttled instead.

Q3. The request value is primarily used to…

Requests are reserved and drive scheduling + QoS; limits are the ceiling.

The three probes + requests vs limits — questions, actions, failures.

recall, then click to reveal

PROBES (kubelet-run): STARTUP "booted yet?" — holds off the others until it passes (for slow starts); READINESS "send traffic?" — fail → removed from Service endpoints, NO restart; LIVENESS "stuck/dead?" — fail → KILL & restart the container. Key: readiness GATES TRAFFIC, liveness RESTARTS — don't swap them. REQUESTS = guaranteed/reserved, drive SCHEDULING + QoS; LIMITS = ceiling — CPU over-limit → THROTTLED, memory over-limit → OOMKILLED (memory can't throttle). REPO: all three probes =

grpc_health_probe
    -addr=localhost:{port}

in _workload_containers.tpl (:92/:117/:137), querying the Go server's gRPC health service; resources from .Values.resources (tom: requests.memory 128Mi).

✅ Part 2 complete You can now connect workloads (Services + DNS, L5), configure them (ConfigMaps/Secrets + SOPS, L6), pick the right controller (StatefulSet vs Deployment — your conversationmgmt, L7), and keep them healthy and sized (probes + resources, L8). Part 3 is production behaviour: autoscaling (KEDA on Kafka lag!), scheduling, disruptions/PDB, and namespaces/RBAC.

Ready for Part 3 (autoscaling/KEDA, scheduling, PDB, RBAC)? Or a mock interview across Parts 1–2 — readiness-vs-liveness is a perfect thing to prove out loud. Ask me.

1. Kubernetes — Liveness, Readiness & Startup Probes.

2. Kubernetes — Managing resources for containers.