Readiness probe concept in Kubernetes - Commands & Configuration

Introduction

Sometimes an application inside a container takes time to start and be ready to serve traffic. A readiness probe helps Kubernetes know when the app is ready so it only sends user requests to containers that can handle them.

When your app needs to load data or initialize before it can accept requests

When you want to avoid sending traffic to a container that is still starting up

When you want Kubernetes to automatically stop sending traffic if your app becomes unhealthy

When you want to improve user experience by only routing to ready containers

When you want to manage rolling updates smoothly by checking readiness before switching traffic

Config File - readiness-pod.yaml

readiness-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: example-readiness-pod
spec:
  containers:
  - name: example-app
    image: nginx:1.23
    readinessProbe:
      httpGet:
        path: /index.html
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 5

This YAML file defines a Pod with one container running nginx.

The readinessProbe uses an HTTP GET request to check if the /index.html page is available on port 80.

initialDelaySeconds waits 5 seconds before the first check to give the app time to start.

periodSeconds sets the probe to run every 5 seconds.

Commands

This command creates the Pod with the readiness probe configured. Kubernetes will start the container and begin checking readiness after the initial delay.

Terminal

kubectl apply -f readiness-pod.yaml

Expected Output

pod/example-readiness-pod created

This command shows the status of the Pod including if it is ready to receive traffic.

Terminal

kubectl get pods example-readiness-pod

Expected Output

NAME                   READY   STATUS    RESTARTS   AGE

example-readiness-pod   1/1     Running   0          10s

This command gives detailed information about the Pod, including readiness probe results and events.

Terminal

kubectl describe pod example-readiness-pod

Expected Output

Name:         example-readiness-pod

Namespace:    default

Status:       Running

Containers:

  example-app:

    Container ID:   docker://abcdef123456

    Image:          nginx:1.23

    Ready:          True

    Restart Count:  0

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

Events:

  Type    Reason     Age   From               Message

  ----    ------     ----  ----               -------

  Normal  Scheduled  1m    default-scheduler  Successfully assigned default/example-readiness-pod to node-1

  Normal  Pulled     1m    kubelet            Container image "nginx:1.23" already present on machine

  Normal  Created    1m    kubelet            Created container example-app

  Normal  Started    1m    kubelet            Started container example-app

Key Concept

If you remember nothing else from this pattern, remember: readiness probes tell Kubernetes when your app is ready to receive traffic, preventing requests from going to containers that are not yet ready.

Common Mistakes

Not setting initialDelaySeconds causing the probe to fail before the app starts

The probe runs too early and marks the container as not ready even though it is just starting up.

Set initialDelaySeconds to a value that gives your app enough time to start before the first probe.

Using a wrong path or port in the readiness probe

The probe will always fail because it cannot reach the correct endpoint, so Kubernetes never marks the container ready.

Verify the path and port in the readiness probe match what your app actually serves.

Confusing readiness probe with liveness probe

Readiness controls traffic routing, liveness controls container restarts; mixing them can cause unexpected restarts or traffic issues.

Use readiness probes to control traffic and liveness probes to check if the container should be restarted.

Summary

Create a Pod with a readiness probe that checks an HTTP endpoint to confirm the app is ready.

Use kubectl apply to create the Pod and kubectl get pods to check if it is ready.

Use kubectl describe pod to see detailed readiness probe results and events.

Practice

1. What is the main purpose of a readiness probe in Kubernetes?

easy

A. To tell Kubernetes when a container is ready to receive traffic

B. To restart a container if it crashes

C. To monitor the CPU usage of a container

D. To update the container image automatically

Solution

1. Step 1: Understand readiness probe role

   A readiness probe checks if a container is ready to accept requests, preventing traffic to unready containers.

2. Step 2: Compare with other options

   Other options describe different Kubernetes features: restarts (liveness probe), monitoring (metrics), and updates (deployments).

3. Final Answer:

   To tell Kubernetes when a container is ready to receive traffic -> Option A

4. Quick Check:

   Readiness probe = container readiness [OK]

Hint: Readiness probe controls traffic flow to containers [OK]

Common Mistakes:

• Confusing readiness probe with liveness probe
• Thinking readiness probe restarts containers
• Assuming readiness probe monitors resource usage

2. Which of the following is a valid way to define a readiness probe in a Kubernetes pod spec?

easy

A. readinessProbe:
httpGet:
path: /health
port: 8080

B. readinessProbe:
restartPolicy: Always

C. readinessProbe:
exec:
command: ["curl", "-f", "http://localhost:8080"]

D. readinessProbe:
tcpSocket:
port: 8080

Solution

1. Step 1: Review readiness probe types

   Valid readiness probes include httpGet, tcpSocket, and exec commands.

2. Step 2: Check syntax correctness

   readinessProbe: httpGet: path: /health port: 8080 is now correctly indented. readinessProbe: exec: command: ["curl", "-f", "http://localhost:8080"] uses exec with correct command syntax as a list of strings. readinessProbe: tcpSocket: port: 8080 correctly defines tcpSocket with port. readinessProbe: restartPolicy: Always is invalid because restartPolicy is not part of readiness probe.

3. Final Answer:

   readinessProbe with tcpSocket and port -> Option D

4. Quick Check:

   Valid readiness probe syntax = tcpSocket [OK]

Hint: Check indentation and valid probe keys for readiness probe [OK]

Common Mistakes:

• Misplacing restartPolicy inside readinessProbe
• Incorrect command format in exec probe
• Wrong indentation causing YAML errors

3. Given this readiness probe configuration in a pod spec:

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10

What happens if the HTTP GET request to /ready returns status 503?

medium

A. Kubernetes ignores the failure and continues sending traffic

B. Kubernetes restarts the container immediately

C. Kubernetes marks the container as not ready and stops sending traffic

D. Kubernetes deletes the pod

Solution

1. Step 1: Understand readiness probe failure effect

   If the readiness probe fails (like HTTP 503), Kubernetes marks the container as not ready and stops routing traffic to it.

2. Step 2: Differentiate from liveness probe

   Liveness probe failure causes restarts, but readiness probe failure only affects traffic routing, not container lifecycle.

3. Final Answer:

   Kubernetes marks the container as not ready and stops sending traffic -> Option C

4. Quick Check:

   Readiness failure = no traffic [OK]

Hint: Readiness failure stops traffic, does not restart container [OK]

Common Mistakes:

• Confusing readiness probe failure with liveness probe failure
• Assuming container restarts on readiness failure
• Thinking pod gets deleted on readiness failure

4. You defined this readiness probe in your pod YAML:

readinessProbe:
  exec:
    command: ["cat", "/tmp/ready"]
  initialDelaySeconds: 5
  periodSeconds: 10

But Kubernetes always marks the pod as not ready. What is the most likely cause?

medium

A. The exec command syntax is invalid

B. The file /tmp/ready does not exist or is empty

C. initialDelaySeconds is too short

D. periodSeconds is too long

Solution

1. Step 1: Understand exec readiness probe behavior

   The exec probe runs the command; it expects a zero exit code for success. If the file /tmp/ready does not exist, cat returns non-zero, causing failure.

2. Step 2: Check other options

   Command syntax is valid. Timing values affect delay but not constant failure. So the missing or unreadable file is the cause.

3. Final Answer:

   The file /tmp/ready does not exist or is empty -> Option B

4. Quick Check:

   Exec probe success = command exit code 0 [OK]

Hint: Exec probe needs command to succeed (exit code 0) [OK]

Common Mistakes:

• Assuming timing values cause readiness failure
• Misunderstanding exec command success criteria
• Ignoring file existence for exec probes

5. You want to ensure your web server container only receives traffic after it finishes loading configuration and opens port 8080. Which readiness probe setup best achieves this?

hard

A. Use an exec readiness probe that runs a script checking config file and port status

B. Use an HTTP GET readiness probe on path /health with periodSeconds set to 1

C. Use a TCP socket readiness probe on port 8080 with initialDelaySeconds set to 10

D. Use a liveness probe instead of readiness probe to check port 8080

Solution

1. Step 1: Analyze readiness probe requirements

   The container must be ready only after config is loaded and port is open. TCP socket or HTTP GET alone cannot check config loading.

2. Step 2: Evaluate probe options

   Use a TCP socket readiness probe on port 8080 with initialDelaySeconds set to 10 checks only port open after delay, Use an HTTP GET readiness probe on path /health with periodSeconds set to 1 checks HTTP path frequently but not config. Use an exec readiness probe that runs a script checking config file and port status runs a script that can verify both config and port, making it the best choice. Use a liveness probe instead of readiness probe to check port 8080 is wrong because liveness probes do not control traffic routing.

3. Final Answer:

   Use an exec readiness probe that runs a script checking config file and port status -> Option A

4. Quick Check:

   Complex readiness checks need exec probe [OK]

Hint: Use exec probe for multi-condition readiness checks [OK]

Common Mistakes:

• Using liveness probe instead of readiness probe
• Relying only on TCP or HTTP probes for config readiness
• Ignoring initialDelaySeconds impact on readiness