Orchestration Core
Config, secrets & health probes
Lesson 4 of 5
What you'll learn
- Separate configuration and credentials from images via ConfigMaps and Secrets
- Distinguish liveness (restart) from readiness (route) probes
- Understand why readiness — not liveness — gates whether a Pod gets traffic
A container image should be environment-agnostic. ConfigMaps hold non-sensitive configuration; Secrets hold credentials. Both inject into Pods as environment variables or mounted files, keeping config out of the image and out of source control.
spec:
containers:
- name: api
envFrom:
- configMapRef:
name: api-config
- secretRef:
name: api-secrets
Liveness vs readiness
Two probes answer two different questions:
- Liveness: "Is this process wedged?" If it fails, the kubelet restarts the container.
- Readiness: "Can this Pod serve requests right now?" If it fails, the Pod is pulled from Service endpoints — no restart, just no traffic.
readinessProbe:
httpGet:
path: /healthz
port: 8080
periodSeconds: 5
livenessProbe:
httpGet:
path: /livez
port: 8080
initialDelaySeconds: 15
Readiness gates traffic
This is the load-bearing distinction. A Pod that is warming a cache, draining, or briefly overloaded should fail readiness — it stays alive but stops receiving requests until it recovers. Confusing the two (e.g. failing liveness during a slow startup) causes restart loops that never let the Pod stabilize.
Only ready Pods get traffic
A Service's endpoint list contains exactly the Pods passing readiness. Failing readiness is the graceful way to say "route around me" without being killed.
Run it. Requests are load-balanced only across Pods reporting ready; unready Pods stay in the fleet but receive nothing.
Which probe determines whether a Pod is removed from a Service's endpoints without being restarted?
Saved on this device. Sign in to sync your progress everywhere.