How to Add Liveness and Readiness Probes to a Kubernetes Deployment

What each probe does

Kubernetes ships two health-check hooks on every container:

• readinessProbe - controls whether the pod receives traffic. While the probe fails, the pod is removed from the Service's endpoint list. Traffic won't hit it until the probe passes. Essential during startup and rolling updates.
• livenessProbe - controls whether the container is restarted. If the probe fails repeatedly (based on failureThreshold), Kubernetes kills and restarts the container. This recovers hung processes that are still "running" but no longer serving.

Without these probes, every pod gets traffic the instant it starts (before the app is up), and a deadlocked process sits there forever instead of being recycled.

Adding probes to a Deployment

Both probes go inside the container spec. For an HTTP server listening on port 80:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web
        image: nginx:1.27-alpine
        ports:
        - containerPort: 80
        readinessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 3
          periodSeconds: 5
        livenessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 10
          periodSeconds: 10

Apply and verify the rollout completes cleanly:

kubectl apply -f deployment.yaml
kubectl rollout status deployment/web

Tuning the timing parameters

Getting initialDelaySeconds wrong is the most common probe mistake:

• readinessProbe.initialDelaySeconds - how long to wait before the first readiness check. Set it just long enough for the app to start (3-5 s for nginx, longer for a JVM app). Too low = pod gets marked not-ready and restarts during startup.
• livenessProbe.initialDelaySeconds - should be longer than readiness, giving the app time to fully initialize before Kubernetes will kill it. A too-short liveness delay causes a restart loop on startup.
• periodSeconds - how often to run the check. 5 s for readiness (fast traffic recovery) and 10 s for liveness (avoid killing a pod over a brief hiccup) is a common baseline.

Other probe types

httpGet is the most common, but Kubernetes supports two others:

• tcpSocket - tries to open a TCP connection on a port. Good for non-HTTP services like a database or message queue.
• exec - runs a command inside the container and checks the exit code (0 = healthy). Useful when the app has a built-in health-check CLI.

A dedicated /healthz or /ready endpoint (separate from your main routes) is better than probing / in production - it lets you signal readiness independently of serving actual requests.