Why probes keep applications healthy in Kubernetes - Why It Works

Introduction

Applications can stop working properly without showing obvious errors. Probes help Kubernetes check if an app is running and ready to serve users. They keep apps healthy by restarting or stopping traffic to broken parts automatically.

When you want Kubernetes to restart an app that is stuck or crashed without manual help

When you want to stop sending user requests to an app that is not ready yet

When you want to detect if an app is alive and fix it quickly if it is not

When you want to improve your app's reliability by automatic health checks

When you want to avoid downtime caused by apps that appear running but are not working

Config File - pod.yaml

pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: my-app-container
    image: nginx:1.23
    livenessProbe:
      httpGet:
        path: /healthz
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 10
    readinessProbe:
      httpGet:
        path: /ready
        port: 80
      initialDelaySeconds: 3
      periodSeconds: 5

This pod runs an nginx container with two probes:

• livenessProbe: Checks if the app is alive by requesting /healthz on port 80. If it fails, Kubernetes restarts the container.
• readinessProbe: Checks if the app is ready to serve traffic by requesting /ready on port 80. If it fails, Kubernetes stops sending traffic to this pod.
• initialDelaySeconds: Wait time before starting probes to allow app startup.
• periodSeconds: How often to run the probe checks.

Commands

This command creates the pod with the configured liveness and readiness probes so Kubernetes can start monitoring the app's health.

Terminal

kubectl apply -f pod.yaml

Expected Output

pod/my-app created

This command shows the status of the pod to verify it is running and ready after applying the probes.

Terminal

kubectl get pods

Expected Output

NAME      READY   STATUS    RESTARTS   AGE

my-app    1/1     Running   0          10s

This command shows detailed information about the pod including probe results and any restarts triggered by failed liveness probes.

Terminal

kubectl describe pod my-app

Expected Output

Name:         my-app

Namespace:    default

Containers:

  my-app-container:

    Container ID:   docker://abcdef123456

    Image:          nginx:1.23

    State:          Running

    Ready:          True

    Restart Count:  0

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

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

Key Concept

If you remember nothing else from this pattern, remember: probes let Kubernetes check app health and fix problems automatically by restarting or stopping traffic.

Common Mistakes

Not setting initialDelaySeconds causing probes to run before app is ready

Probes may fail immediately and cause unnecessary restarts or mark the app as not ready

Set initialDelaySeconds to allow the app enough time to start before probes begin

Using the same probe for both liveness and readiness

Liveness and readiness have different purposes; using one probe for both can cause wrong behavior like restarting healthy apps or sending traffic to unready apps

Configure separate liveness and readiness probes tailored to their specific checks

Not defining readiness probe causing traffic to be sent to unready pods

Without readiness probe, Kubernetes assumes the pod is always ready and may send requests to an app that is still starting or unhealthy

Always define a readiness probe to control when the pod receives traffic

Summary

Define liveness and readiness probes in your pod spec to let Kubernetes monitor app health.

Use liveness probes to restart stuck or crashed containers automatically.

Use readiness probes to control when your app receives user traffic.

Apply the pod manifest and verify pod status and probe results with kubectl commands.