Readiness and liveness probes
Probes are how Kubernetes knows a pod is ready and still alive. Readiness gates traffic. Liveness triggers restart. Both should hit an endpoint that reflects the real state of the service, not just whether a TCP port is open.
readinessProbe:
httpGet:
path: /enterprise-rag/health
port: http
initialDelaySeconds: 20
periodSeconds: 10
livenessProbe:
httpGet:
path: /enterprise-rag/health
port: http
initialDelaySeconds: 45
periodSeconds: 30initialDelaySeconds: 20 on readiness gives the embedding model time to load before the pod starts receiving traffic. Liveness waits longer (45s) so a slow but legitimate startup does not trigger a restart loop.
They ask different questions. Readiness asks: should this pod receive traffic right now? A failing readiness check takes the pod out of the Service endpoints without killing it. Liveness asks: is this pod stuck and should we restart it? A failing liveness check triggers a hard restart. Collapsing them means a blip forces an unnecessary restart.
One more probe completes the set: the startup probe. It runs first, and until it succeeds Kubernetes holds back both the readiness and liveness checks. For a service with a slow first load, like an embedding model pulling weights, it stops the liveness probe from killing a pod that is merely warming up.
Matching exercise: Match each probe to its effect
Loading practice…
Checkpoint: Kubernetes deploy checkpoint
Loading practice…