KodeKloud Notes

In this guide, you’ll learn how Kubernetes readiness probes contribute to observability and reliability by controlling when your Pods receive traffic. We’ll cover Pod lifecycle phases, conditions, probe types, configuration options, and best practices for multi-Pod deployments.

Pod Lifecycle Recap

A Pod transitions through several high-level phases:

Pending: Scheduler is selecting a node.
ContainerCreating: Image pull and container startup.
Running: All containers have started successfully.

Check the current phase:

kubectl get pods

The image shows a "POD Status" screen with labels "Pending" and "ContainerCreating," along with three colored bars and a circular loading icon.

For more detail on each Pod, use:

kubectl describe pod <pod-name>

Understanding Pod Conditions

Pod conditions are booleans that provide deeper insights:

PodScheduled: Has the scheduler assigned a node?
Initialized: Have init containers completed?
ContainersReady: Are all containers in Running state?
Ready: Is the Pod prepared to serve requests?

The image shows a diagram titled "POD Conditions" with four conditions: PodScheduled, Initialized, ContainersReady, and Ready, each having "TRUE" and "FALSE" options. There is also a circular diagram with three smaller circles inside.

Inspect conditions directly:

kubectl describe pod <pod-name>

Note

By default, Kubernetes marks the Ready condition as True once containers start, even if the application isn’t fully initialized.

Why Readiness Probes Matter

Without readiness probes, a Service may route traffic to a Pod before its application is ready, resulting in errors for end users. Readiness probes let you tie the Ready condition to an actual in-container health check.

The image illustrates "Readiness Probes" with icons and labels for HTTP Test, TCP Test, and Exec Command.

Probe Types

Type	Description	Example Snippet
HTTP GET	Performs an HTTP GET request against a path	`httpGet: { path: "/ready" }`
TCP Socket	Attempts a TCP connection on a port	`tcpSocket: { port: 3306 }`
Exec	Runs a command inside the container	`exec: { command: ["cat"] }`

Configuring Readiness Probes

Add a readinessProbe block under your container spec:

1. HTTP GET Probe

apiVersion: v1
kind: Pod
metadata:
  name: simple-webapp
spec:
  containers:
    - name: simple-webapp
      image: simple-webapp:latest
      ports:
        - containerPort: 8080
      readinessProbe:
        httpGet:
          path: /api/ready
          port: 8080

2. TCP Socket Probe

readinessProbe:
  tcpSocket:
    port: 3306

3. Exec Command Probe

readinessProbe:
  exec:
    command:
      - cat
      - /app/is_ready

Customizing Probe Timing

Fine-tune how and when probes run:

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

Parameter	Description	Default
initialDelaySeconds	Seconds to wait before first probe	0
periodSeconds	Interval between each probe	10
failureThreshold	Number of failures before marking as fail	3

Note

Consider also configuring liveness probes to restart unhealthy containers.

Readiness in a Scaled Deployment

When you scale a Deployment, only Pods that pass their readiness probe will start receiving traffic. This prevents service disruptions caused by uninitialized instances.

The image shows a diagram labeled "POD Conditions" with a green triangle connected to three blue circles, each marked as "Ready" with checkmarks. There are also two browser windows above the triangle, one showing "SUCCESS."

Warning

Ensure your readiness probe endpoint is lightweight and fast to avoid delaying traffic routing.

Links and References

Watch Video

Watch video content