Mastering Kubernetes Init Containers: Lifecycle, Best Practices, and Hands‑On Examples
This article explains the Kubernetes pod lifecycle, detailing each phase from API server creation to readiness and liveness probes, and provides an in‑depth guide to init containers, their advantages, special considerations, and step‑by‑step YAML examples with commands to demonstrate initialization and troubleshooting.
Lifecycle
1. API server calls kubelet to issue a Pod creation command.
2. Container environment initialization.
3. Enter Pod lifecycle (Pod creation starts).
4. When a Pod is created, a pause container is automatically generated to share network and storage.
5. Init containers (init C) perform initialization.
6. Init containers run only for initialization; after completion they are automatically terminated.
7. Init containers cannot run in parallel; each must finish before the next starts.
8. If an init container fails, Kubernetes repeatedly restarts the Pod until the init container succeeds, unless the Pod's restartPolicy is set to
Never.
9. Main container starts.
10. The main container performs START (command executed on entry) and STOP (command executed before exit) operations.
11. Readiness probe can be configured with custom intervals.
12. Liveness probe checks whether the container can serve; if not, appropriate recovery actions are taken.
Init Container Example
Advantages:
They can contain useful utilities, but for security reasons such tools should not be included in the application container image.
They can run custom scripts or install tools, avoiding the need to embed these utilities in the final application image.
The application image can be separated from build‑time responsibilities, eliminating the need to combine creation and deployment into a single image.
Init containers use Linux namespaces, giving them a different filesystem view and allowing access to Secrets that the application container cannot see.
Init containers must complete before the application containers start, providing a simple blocking mechanism until prerequisite conditions are satisfied.
<code>## Edit Pod manifest
vim initc.yaml
...
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
version: v1
spec:
containers:
- name: myapp-container
image: busybox:v1
command: ['sh','-c','echo The app is running! && sleep 3600']
imagePullPolicy: IfNotPresent
initContainers:
- name: init-myapp
image: busybox:v1
command: ['sh','-c','until cat /root/myapp;do echo /root/myapp no such file or directory!;sleep 2;done']
imagePullPolicy: IfNotPresent
- name: init-mydb
image: busybox:v1
command: ['sh','-c','until cat /root/mydb;do echo /root/mydb no such file or directory!;sleep 2;done']
imagePullPolicy: IfNotPresent
...
## Create Pod
kubectl create -f initc.yaml
pod/myapp-pod created
## Check Pod status
kubectl get pod # STATUS shows init not completed
NAME READY STATUS RESTARTS AGE
myapp-pod 0/1 Init:0/2 0 3m26s
## View Pod description
kubectl describe pod myapp-pod
## View init container logs (failure)
kubectl log myapp-pod -c init-myapp
cat: can't open '/root/myapp': No such file or directory
## Create the required file to satisfy init container
kubectl exec -it myapp-pod -c init-myapp -- touch /root/myapp
kubectl get pod
NAME READY STATUS RESTARTS AGE
myapp-pod 0/1 Init:1/2 0 5m19s
## Create second file for second init container
kubectl exec -it myapp-pod -c init-mydb -- touch /root/mydb
kubectl get pod
NAME READY STATUS RESTARTS AGE
myapp-pod 1/1 Running 0 7m50s
## Once init containers finish, they disappear</code>Init Container Special Notes
If a Pod restarts, all init containers are re‑executed.
During Pod startup, init containers run after the network and volume (pause container) are initialized, and each must exit before the next starts.
If an init container fails, the restart behavior follows the Pod's
restartPolicy; with
Always, failed init containers trigger the policy.
The Pod will not reach Ready state until all init containers succeed; until then it remains in Pending/Initializing.
Modifications to an init container's spec are limited to the
imagefield; changing other fields has no effect and updating the image effectively restarts the Pod.
Raymond Ops
Linux ops automation, cloud-native, Kubernetes, SRE, DevOps, Python, Golang and related tech discussions.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.