Kubernetes Probes

Why Probes Matter

A container can be running but still unhealthy. It may be stuck, warming up, or unable to serve traffic. Probes help Kubernetes respond intelligently.

Probe Types

Liveness Probe

If the liveness probe fails repeatedly, Kubernetes restarts the container.

Readiness Probe

If the readiness probe fails, Kubernetes stops sending Service traffic to that pod.

Startup Probe

A startup probe gives slow-starting apps extra time before liveness checks begin.

Probe Method Comparison

Full YAML Example

apiVersion: v1
kind: Pod
metadata:
  name: probed-app
spec:
  containers:
    - name: web
      image: nginx:1.27
      ports:
        - containerPort: 80
      startupProbe:
        httpGet:
          path: /
          port: 80
        failureThreshold: 30
        periodSeconds: 5
      livenessProbe:
        httpGet:
          path: /
          port: 80
        initialDelaySeconds: 10
        periodSeconds: 10
      readinessProbe:
        tcpSocket:
          port: 80
        initialDelaySeconds: 5
        periodSeconds: 5

Why These Three Probes Are Different

• startupProbe protects slow startup
• livenessProbe answers "should I restart this?"
• readinessProbe answers "should I send traffic to this right now?"

Common Mistakes

Liveness Too Aggressive

If the liveness probe is too strict, Kubernetes may restart a healthy but slow app repeatedly.

No Readiness Probe

Without readiness checks, traffic may hit an app before it is actually ready.

Confusing Readiness with Liveness

Readiness should remove traffic. Liveness should recover a broken container.

Think of readiness like opening the front door for customers and liveness like deciding whether the shop is broken badly enough to reboot the entire register system.