What does READY 1/2 mean in kubectl get pods?

READY shows how many containers are ready, out of the total. For the checkout Pod, 1/2 means it has two containers, and only one passes its readiness check. STATUS still says Running, so the Pod looks fine at a glance, but one container isn't ready.

Here's the checkout Pod. It runs two containers: app, which is healthy and passes its readiness check, and proxy, a sidecar whose readiness probe fails because it can't load its config file. App counts one. Proxy counts zero. That's why the Pod shows one out of two.

A Pod is Ready only when every container in it is ready. The app is healthy, but the proxy isn't, and that one failure blocks the whole Pod. A Service routes only to Ready Pods, so checkout-7d9f8c-x2k4p isn't an endpoint, and a healthy app still gets nothing.

Follow the chain. The kubelet runs the readiness probe against proxy, and proxy fails because it has no config. The kubelet then reports the Pod as Ready false to the control plane. That triggers the removal of this Pod's endpoint from the checkout Service. From then on, traffic skips this Pod, even though app is perfectly healthy.

STATUS and READY answer different questions. Running means the Pod's containers have started and their processes are alive. READY asks whether each container's readiness probe passes. Here, proxy is running but not ready, and both are true at once. So a Pod can look healthy by status and still be out of rotation.

READY 1/2 points you to checkout-7d9f8c-x2k4p, but it doesn't say which container is failing or why. For that, we need to look inside the Pod.

Run kubectl describe on the Pod and look at the Containers section. App is Ready True, but proxy is Ready False, even though it's Running. Below that, the Pod's Ready condition is False, and the Events show the kubelet reporting a failed readiness probe with a 503. This output is trimmed and illustrative.

Describe told us which container, and now the logs tell us why. The dash c flag picks the container, and in a multi-container Pod you need it. Here, proxy reports it failed to load its config file. Fix that config, and READY becomes 2 out of 2, so the Pod rejoins the Service.

A few caveats. Init containers aren't counted in READY, since they finish before the Pod starts serving. Native sidecars may show counts differently in newer versions. And a failing readiness probe only removes traffic. It doesn't restart anything, unlike liveness.

Every container ready, or no traffic. One unready container makes the whole Pod unready, so the Service leaves it out of its endpoints, even when app is healthy. When you see 1/2 in get pods, run describe to find the container, then logs with dash c to learn why.