Kubernetes Fundamentals · Module 09 of 14

Liveness, readiness and startup probes

Separate process health from traffic readiness and use probes so Kubernetes can restart unhealthy containers and remove unready Pods from Service endpoints.

Learning objectives

By the end of this module, you should be able to:

Explain liveness versus readiness.
Recognize when a startup probe protects slow-starting applications.
Configure HTTP probes and observe readiness.

Readiness controls traffic eligibility

A failed readiness probe marks the Pod unready. Services stop considering that Pod ready for normal traffic, but the container is not restarted merely because readiness failed.

Liveness asks whether restart may help

Repeated liveness failure causes kubelet to restart the affected container according to Pod restart behavior. Poor liveness probes can create restart loops during temporary dependency problems.

Startup probes gate the other probes

When configured, startup probes allow slow initialization without liveness/readiness acting too early. After startup succeeds, normal probes take over.

Worked examples

See the idea in practice.

Probe an HTTP container

readinessProbe:
  httpGet:
    path: /
    port: 80
  initialDelaySeconds: 1
  periodSeconds: 2
livenessProbe:
  httpGet:
    path: /
    port: 80
  initialDelaySeconds: 5
  periodSeconds: 5

Readiness affects endpoint eligibility.
Liveness can trigger a restart after configured failures.

Hands-on lab

Lab — Observe readiness and liveness

Goal: Deploy nginx with HTTP probes and verify both Deployment readiness and Service endpoints.

Before you start

kubectl is installed and can reach the lab cluster.
Use the dedicated gnu-k8s-fundamentals namespace unless a step explicitly says otherwise.

STEP 1

Apply a probed Deployment and Service

cat <<'EOF' | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: probe-web
  namespace: gnu-k8s-fundamentals
spec:
  replicas: 2
  selector:
    matchLabels: {app: probe-web}
  template:
    metadata:
      labels: {app: probe-web}
    spec:
      containers:
      - name: nginx
        image: nginx:alpine
        ports: [{containerPort: 80}]
        readinessProbe:
          httpGet: {path: /, port: 80}
          periodSeconds: 2
        livenessProbe:
          httpGet: {path: /, port: 80}
          initialDelaySeconds: 3
          periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
  name: probe-web
  namespace: gnu-k8s-fundamentals
spec:
  selector: {app: probe-web}
  ports: [{port: 80, targetPort: 80}]
EOF

STEP 2

Wait for rollout

kubectl -n gnu-k8s-fundamentals rollout status deployment/probe-web --timeout=120s

STEP 3

Inspect readiness and endpoints

kubectl -n gnu-k8s-fundamentals get pods -l app=probe-web
kubectl -n gnu-k8s-fundamentals get endpointslices -l kubernetes.io/service-name=probe-web

STEP 4

Clean up

kubectl -n gnu-k8s-fundamentals delete service probe-web
kubectl -n gnu-k8s-fundamentals delete deployment probe-web

Verify

Both Pods become Ready.
The EndpointSlice contains ready backends.

Expected outcome

The Deployment reports successfully rolled out.

If it fails

If readiness never succeeds, test the same path/port inside the Pod.
Do not point liveness at a dependency whose temporary failure should not restart your application.

Real-world connection

Well-designed probes let rolling updates and Services make decisions based on application health rather than only process existence.

Avoid these traps

Common mistakes

Using the same aggressive probe for every application.
Making liveness depend on an external database that can fail independently.
Assuming a readiness failure restarts the container.

Knowledge check

Can you explain it without looking back?

Open each answer only after you have tried to answer the question yourself.

1Which probe controls whether a Pod should receive Service traffic?

Readiness.

2Which probe can cause kubelet to restart a container?

Liveness.

3Why use a startup probe?

To protect slow-starting applications from normal liveness/readiness checks until startup succeeds.