Cloud Native 8 min read

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.

Raymond Ops
Raymond Ops
Raymond Ops
Mastering Kubernetes Init Containers: Lifecycle, Best Practices, and Hands‑On Examples

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

image

field; changing other fields has no effect and updating the image effectively restarts the Pod.

KubernetesyamlReadiness ProbePod LifecycleLiveness ProbeInit Containers
Raymond Ops
Written by

Raymond Ops

Linux ops automation, cloud-native, Kubernetes, SRE, DevOps, Python, Golang and related tech discussions.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.