Hands-on Lab·Certified Kubernetes Administrator
Troubleshooting Init Container Failures
A Pod held before its application ever starts. This reads the state, gets the right logs out, and shows why the ordering guarantee turns one failing init container into a Pod that never runs.
Troubleshooting Guide 84 of 103 Beginner
- Kubernetes1.36.4
- Cluster4 nodes
- Runtimecontainerd 2.2.6
- CNICalico v3.32.1
- TimeAbout 15 min
Restart counts and backoff timings are this run's. Which of the two Init states you catch depends only on when you look.
| 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 is held before its application ever starts. This matters because kubectl logs on the Pod hands back an unhelpful error rather than the answer, and the reason lives in a container you have to name explicitly.
- writing an init container that cannot do its job, and seeing the Pod held before the app runs
- finding out why
kubectl logs appdoes not help, and naming the init container instead - reading the exit code out of
describe, which is the part actually worth having - running two init containers and confirming they run strictly in order
- fixing it, and discovering that a container's command is immutable on a running Pod
Before you start
- guide 31 - what init containers are for, before this covers what they do when they fail.
-
An init container that fails
-
Where the reason actually is
-
What describe adds
-
Two init containers, and the order they run in
-
Fix the first Pod