HTTP probe configuration in Kubernetes - Commands & Configuration

Introduction

Sometimes your app might stop responding or crash. Kubernetes can check your app's health by sending simple web requests called HTTP probes. This helps Kubernetes restart or stop your app if it is not working properly.

When you want Kubernetes to check if your web app is running and responding.

When you want to restart your app automatically if it stops responding.

When you want to make sure traffic only goes to healthy app instances.

When you want to detect if your app is ready to accept traffic after starting.

When you want to avoid sending users to broken or crashed app copies.

Config File - pod.yaml

pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: nginx:1.23
    ports:
    - containerPort: 80
    readinessProbe:
      httpGet:
        path: /healthz
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 10
    livenessProbe:
      httpGet:
        path: /healthz
        port: 80
      initialDelaySeconds: 15
      periodSeconds: 20

This file creates a pod running an Nginx web server.

readinessProbe checks if the app is ready to receive traffic by sending an HTTP GET request to /healthz on port 80, starting 5 seconds after the container starts, and repeats every 10 seconds.

livenessProbe checks if the app is alive by sending the same HTTP GET request, starting 15 seconds after the container starts, repeating every 20 seconds. If this fails, Kubernetes restarts the container.

Commands

This command creates the pod with the HTTP probes configured. Kubernetes starts the pod and begins checking its health.

Terminal

kubectl apply -f pod.yaml

Expected Output

pod/example-pod created

This command lists all pods and shows their status to verify if the pod is running and ready.

Terminal

kubectl get pods

Expected Output

NAME          READY   STATUS    RESTARTS   AGE

example-pod   1/1     Running   0          10s

This command shows detailed information about the pod, including the status of readiness and liveness probes.

Terminal

kubectl describe pod example-pod

Expected Output

Name:         example-pod

Namespace:    default

Containers:

  example-container:

    Container ID:   docker://abcdef123456

    Image:          nginx:1.23

    State:          Running

    Ready:          True

    Restart Count:  0

    Liveness:       http-get http://:80/healthz delay=15s timeout=1s period=20s #success=1 #failure=3

    Readiness:      http-get http://:80/healthz delay=5s timeout=1s period=10s #success=1 #failure=3

Conditions:

  Type              Status

  Initialized       True 

  Ready             True 

  ContainersReady   True 

  PodScheduled      True 

Key Concept

If you remember nothing else from this pattern, remember: HTTP probes let Kubernetes check your app’s health by sending simple web requests and act if the app is not responding.

Common Mistakes

Not setting initialDelaySeconds causing probes to run before the app is ready.

Probes may fail immediately, causing Kubernetes to restart the app unnecessarily.

Set initialDelaySeconds to a few seconds to give the app time to start before probing.

Using wrong path or port in the httpGet probe.

Kubernetes will get errors because it cannot reach the correct endpoint, marking the app unhealthy.

Use the exact path and port your app exposes for health checks.

Not distinguishing readinessProbe and livenessProbe roles.

Readiness controls traffic routing; liveness controls restarts. Mixing them can cause traffic to go to unhealthy pods or unnecessary restarts.

Use readinessProbe to check if app is ready for traffic, livenessProbe to check if app is alive.

Summary

Create a pod manifest with readinessProbe and livenessProbe using httpGet to check app health.

Apply the pod manifest with kubectl apply -f pod.yaml to start the pod and probes.

Use kubectl get pods and kubectl describe pod to verify pod status and probe results.