In Kubernetes, when you execute the command kubectl get pod $yourpod, you're accessing detailed information about the specified pod. Amongst the columns presented, you'll often see an entry denoted as READY. This article delves into the meaning of the READY=2/2 output, providing both a technical breakdown and practical examples.

Understanding the READY Column

In the output of kubectl get pod, the READY column provides insights into the status of the containers within a pod. Specifically, it signifies the ratio of containers that are considered "ready" versus the total number of containers within that pod. Each part of the ratio can be interpreted as:

• Current Ready Containers: The number before the slash (/) indicates how many containers in the pod are in a ready state.
• Total Containers: The number after the slash (/) represents the total count of containers that form the pod.

Breaking Down READY=2/2

When you encounter READY=2/2, it signifies that the pod consists of two containers and both are in a ready state. This result is an indicator of healthy and functioning containers within a pod, ready to handle incoming requests and perform their designated tasks.

Example Scenario

Consider a pod designed to host a web application:

• First Container: Hosts a web server like Nginx, which serves static content.
• Second Container: Runs an application server, perhaps Python's Flask, that handles dynamic content processing.

If both containers initialize correctly and pass their respective readiness probes, the READY status will display as 2/2.

Readiness Probes

Readiness probes are a crucial component in determining the "readiness" of each container. They allow Kubernetes to decide whether a container is ready to start accepting traffic.

• HTTP Probes: SEND an HTTP GET request to the container's IP address. If the response is within the desired range (200-399), the container is marked as ready.
• TCP Probes: Attempt to open a TCP connection to the container. Successful connections denote a ready state.
• Command Probes: Execute commands within the container. A successful exit status indicates readiness.

Configuring Readiness Probes

Here's an example of defining a readiness probe for a container in a pod's configuration:

1apiVersion: v1
2kind: Pod
3metadata:
4  name: example-pod
5spec:
6  containers:
7  - name: sample-container
8    image: my-image
9    readinessProbe:
10      httpGet:
11        path: /healthz
12        port: 8080
13      initialDelaySeconds: 5
14      periodSeconds: 10

This configuration checks the /healthz endpoint on port 8080 after an initial delay of 5 seconds, repeating every 10 seconds.

Common READINESS States and Their Implications

Below is a table summarizing various readiness states and their potential implications:

Additional Considerations

• Initial Delays and Timeouts: Often, configuring readiness probes includes setting initial delays and timeouts during which a container can perform startup tasks before being marked as not ready.
• Impact on Service Routing: Kubernetes will route traffic to only those pods where all containers are confirmed by readiness probes, ensuring only fully operational services receive user requests.
• Monitoring and Alerting: It is essential to set up monitoring systems like Prometheus in tandem with Kubernetes to alert when a pod's readiness status is anything other than the expected state.

In conclusion, the READY=2/2 output from kubectl get pod $yourpod acts as a positive indication of your pod's operational health. Understanding this metric, alongside configuring effective readiness probes, is essential for ensuring your services remain robust and responsive within the Kubernetes ecosystem.