Readiness Probes: Controlling Traffic Flow in Kubernetes

Previously in this course, we covered Liveness Probes: Automating Container Reliability in Kubernetes, which focus on restarting containers that have crashed or deadlocked. While liveness probes handle "is it broken?", this lesson focuses on "is it ready?".

When a Pod starts, the container process might be running, but the application inside might still be loading data, warming up caches, or establishing database connections. If Kubernetes sends traffic to your Pod before it's actually ready to handle requests, your users will experience errors or timeouts. Readiness probes act as the gatekeeper for your service traffic.

Understanding Traffic and Load Balancing

In Kubernetes, when you create a Service, it acts as a stable endpoint for your Pods. Without a readiness probe, the The Role of Services: Kubernetes Networking Explained mechanism immediately includes any Pod with a matching label in the service's "endpoints" list as soon as the container enters the Running phase.

Readiness probes change this behavior by decoupling the Pod's lifecycle from its availability to receive traffic. If a probe fails, Kubernetes removes the Pod from the Service's endpoints. Once the probe succeeds, it adds the Pod back. This ensures that Horizontal Scaling and Load Distribution: A Practical Guide works effectively, as traffic only flows to healthy, capable instances.

Implementing a Readiness Probe

Adding a readiness probe is similar to adding a liveness probe. You define a readinessProbe block in your Pod manifest. The most common type is an httpGet probe, which checks if a specific endpoint on your application returns a success code (HTTP 200–399).

Here is a practical example of a Pod manifest with a readiness probe:

YAML
apiVersion: v1
kind: Pod
metadata:
  name: web-app-ready
  labels:
    app: web-app
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80
    readinessProbe:
      httpGet:
        path: /index.html
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 10
      failureThreshold: 3

Breaking Down the Configuration

• httpGet: The action to perform. Here, we check the root path on port 80.
• initialDelaySeconds: How long to wait after the container starts before performing the first probe. Use this if your app takes a few seconds to boot.
• periodSeconds: The frequency of the check.
• failureThreshold: How many consecutive failures are allowed before the Pod is marked "not ready."

Hands-on Exercise

1. Create the web-app-ready.yaml file provided above.
2. Apply it to your cluster: kubectl apply -f web-app-ready.yaml.
3. Check the status of the Pod: kubectl get pods. You will see it transition from Running to Ready 1/1.
4. Deliberately break the probe by changing the path in your YAML to /missing-page.html.
5. Re-apply the manifest. Observe the status change to 0/1 readiness even though the Pod is Running.

Common Pitfalls

• Probing the wrong endpoint: Don't just probe /. If your app relies on a database, create a dedicated /health/ready endpoint that verifies the DB connection.
• Overly aggressive thresholds: If your application is resource-heavy and takes time to start, setting initialDelaySeconds too low will cause the probe to fail repeatedly, causing the Pod to thrash in a "not ready" state.
• Confusing Liveness and Readiness: Remember: Liveness kills and restarts the container (the "nuclear option"). Readiness simply stops sending traffic to the Pod.

FAQ

Q: If my readiness probe fails, does the container restart? A: No. Readiness probes only affect traffic routing. If a Pod is failing its readiness probe, it remains in the Running state but is excluded from the Service's traffic distribution.

Q: Can I use readiness probes for non-web apps? A: Yes. You can use tcpSocket to check if a port is open or exec to run a shell command inside the container (e.g., checking for a lock file).

Q: Do I need both Liveness and Readiness probes? A: Yes, it is best practice to use both. Liveness handles recovery from fatal errors, while readiness manages service-level availability during startup and maintenance.

Recap

Readiness probes are essential for professional-grade deployments. They prevent your users from hitting a partially started application by verifying that the service is actually capable of processing requests. By tuning these probes, you ensure that your traffic is load-balanced only to Pods that are fully initialized and ready to serve.

Up next: We will dive into Resource Requests and Limits, where we explore how to tell Kubernetes exactly how much CPU and memory your Pods need to operate safely.