Hands-on Lab·Certified Kubernetes Administrator
Readiness Failures and Service Endpoints
One Pod taken out of a Service without being restarted, put back without being rescheduled, and then the identical probe moved to livenessProbe so the difference is measured rather than described.
Troubleshooting Guide 88 of 103 Beginner
- Kubernetes1.36.4
- Cluster4 nodes
- Runtimecontainerd 2.2.6
- CNICalico v3.32.1
- TimeAbout 15 min
periodSeconds: 3 here so the transitions are quick to watch. The defaults are 10 seconds and three failures.
| 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 |
This guide includes
Use this when a Pod has to leave a Service without being restarted or rescheduled. This matters because readiness and liveness can be the same probe pointed at two different outcomes - one removes traffic, the other kills the container.
- starting from three replicas that are all present in the Service's endpoints
- breaking readiness on exactly one Pod, from outside the container
- seeing the Deployment count Pods that are Ready rather than Pods that are Running
- restoring the file and measuring how quickly the endpoint comes back
- moving the identical probe to
livenessProbeand watching the container be killed instead
Before you start
- guide 36 - the three probes, before this covers two of them failing.
- guide 98 - the same endpoint list, seen from the Service side.
-
Three replicas, all in the endpoints
-
Break readiness on exactly one Pod
-
What the Deployment thinks
-
Put it back, and see how fast
-
The same failure, expressed as liveness