1. Introduction to Readiness Probes

In Kubernetes, it’s crucial to prevent traffic from reaching a container before it’s ready. A container may take time to initialize (e.g., loading data, compiling templates, establishing connections), during which it should not receive user traffic.

This is exactly what Readiness Probes solve.

A Readiness Probe determines when a container is ready to start serving requests. If the container is not ready, Kubernetes removes the Pod from the associated Service’s endpoints.

Unlike Liveness Probes, failing a readiness probe:

• Does not restart the container.
• Simply removes the Pod from traffic routing until it becomes ready again.

2. Readiness vs Liveness – Key Differences

Aspect	Readiness Probe	Liveness Probe
Purpose	Detects if app is ready to receive traffic	Detects if app is still running/alive
Action on Failure	Pod is removed from Service endpoints	Container is restarted
Restart Behavior	No restart	Restart triggered by kubelet
Runs Until Success?	Keeps checking, even after success	Runs continuously
Restart Trigger?	No	Yes

3. Types of Readiness Probes in Kubernetes

Kubernetes supports three types of readiness probes, similar to liveness probes.

A. HTTP GET Probe

Performs an HTTP GET request to a specified endpoint (e.g., /ready), expecting a 2xx or 3xx response code.

YAML Example:

apiVersion: v1
kind: Pod
metadata:
  name: readiness-http
spec:
  containers:
    - name: readiness
      image: luksa/kubia-unhealthy
      ports:
        - containerPort: 8080
      readinessProbe:
        httpGet:
          path: /
          port: 8080
        initialDelaySeconds: 3
        periodSeconds: 3
        failureThreshold: 3

Explanation:

• After 3 seconds (initialDelaySeconds), Kubernetes starts probing http://localhost:8080/.
• If 3 consecutive failures occur, the Pod is removed from the Service.

B. TCP Socket Probe

Attempts to open a TCP connection to the container. If the connection succeeds, the probe passes.

YAML Example:

apiVersion: v1
kind: Pod
metadata:
  name: readiness-tcp
spec:
  containers:
    - name: goproxy
      image: k8s.gcr.io/goproxy:0.1
      ports:
        - containerPort: 8080
      readinessProbe:
        tcpSocket:
          port: 8080
        initialDelaySeconds: 5
        periodSeconds: 3

Use Case:

Ideal for non-HTTP applications, e.g., raw TCP services.

C. Exec Probe

Executes a command inside the container and checks the exit status.

• Exit code 0: success (ready)
• Non-zero: failure (not ready)

YAML Example:

apiVersion: v1
kind: Pod
metadata:
  name: readiness-exec
spec:
  containers:
    - name: readiness
      image: k8s.gcr.io/busybox
      args:
        - /bin/sh
        - -c
        - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
      readinessProbe:
        exec:
          command:
            - cat
            - /tmp/healthy
        initialDelaySeconds: 5
        periodSeconds: 5

Explanation:

• For the first 30 seconds, /tmp/healthy exists → probe succeeds.
• After that, the file is deleted → probe fails → Pod removed from Service.

4. How Readiness Probes Work

• The kubelet agent on each node executes the probe periodically.
• If the probe fails:
  • The Pod is removed from the Service load balancer.
• If the probe later succeeds:
  • The Pod is re-added to the Service.

This mechanism ensures that only healthy and ready Pods serve user traffic.

5. Best Practices for Using Readiness Probes

Always Define a Readiness Probe

• If your application has any delay in startup (e.g., DB connection, config loading), use a readiness probe.

Use a Lightweight /ready Endpoint

• Should be fast (respond within 1 second)
• Should not require authentication
• Should not check external dependencies

readinessProbe:
  httpGet:
    path: /ready
    port: 8080

Avoid Using Same Spec for Liveness and Readiness

• Readiness determines traffic eligibility.
• Liveness determines restarts.
• Keep them separate. A Pod might be alive but not ready.

Use initialDelaySeconds Wisely

• Prevent premature removal from Service.
• Useful if app needs warmup time.

initialDelaySeconds: 10

Avoid Exec Probes in Production

• They introduce overhead.
• Compatibility issues with container runtimes.
• Prefer HTTP or TCP checks.

Monitor Readiness Probe Failures

• Use kubectl describe pod or kubectl get events to debug.
• Check logs using: kubectl logs <pod-name>

6. Real-world Use Case

In a microservice like a Payment Gateway, which connects to:

• Database
• External APIs
• Cache systems

The app may take 10+ seconds to initialize all components.

Without a readiness probe:

• Kubernetes routes traffic immediately
• Requests during startup might fail

With a readiness probe:

• Pod is kept out of Service routing
• Only starts receiving traffic when fully ready

7. Useful kubectl Commands

# Apply Pod manifest
kubectl apply -f readiness-http.yaml

# Check Pod status
kubectl get pods

# View readiness events
kubectl describe pod readiness-http

# Check container logs
kubectl logs readiness-http

8. Summary Table

Parameter	Purpose
initialDelaySeconds	Wait time before first probe after start
periodSeconds	Time between probe checks
failureThreshold	Number of failures before marking as “not ready”
httpGet, tcpSocket, exec	Methods of probing container readiness

9. Conclusion

Readiness probes are essential for ensuring that traffic only reaches containers that are fully ready to handle it. They prevent user-facing errors during initialization or reconfiguration.

When used correctly, they:

• Improve application stability
• Prevent service disruptions
• Optimize load balancing

Combined with liveness probes, they help Kubernetes maintain both availability and reliability in your microservices.