Pod Phase Versus Readiness
STATUS says Running and the Service answers nothing. Readiness and liveness probes are both health checks and they do completely different jobs: one decides whether traffic reaches the Pod, the other decides whether the container is killed and restarted. This runs one Pod with both, driven by two files, and proves what each one controls with a real client rather than a diagram.
Kubernetes Fundamentals Guide 8 of 46 Beginner
- Kubernetes1.36.4
- Runtimecontainerd 2.2.6
- CNICalico v3.32.1
- Cluster4 nodes
- TimeAbout 15 min
- Reviewed23 August 2026
Written against the versions above. `conditions.ready` on EndpointSlice is the field that matters here. The older Endpoints object expressed the same thing by moving addresses between `addresses` and `notReadyAddresses`; EndpointSlice keeps one list and flags each entry, which is why the address never disappears below.
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| CKA1001 | 192.168.0.175 | Ubuntu 26.04 LTS | Control Plane Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE01 | 192.168.0.176 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE02 | 192.168.0.177 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE03 | 192.168.0.178 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
Before you start
- A cluster and kubectl. Both probes are
execprobes over ordinary files, so nothing needs to be installed or reachable from outside. - The session creates namespace
kx-probe, a Deploymentwebwith a readiness probe on/tmp/readyand a liveness probe on/tmp/live, a Serviceweb, and aclientPod to call it from inside the cluster.
-
One Pod, two probes, two files
-
Running, and refusing every connection
-
One file turns the traffic on
-
The other file gets the container killed