An init container prepares a Kubernetes pod before its regular containers start. Regular containers have no guaranteed dependency order; init containers instead run one at a time, in the order listed in the pod manifest. Each must finish successfully before startup proceeds. section 5.5 section 5.5.1
Use an init container for a task that must happen before the application runs:
- Put configuration, certificates, or other files into a volume shared with a regular container. section 5.5.1
- Adjust networking shared by the pod’s containers. section 5.5.1
- Wait for a required service to become available, or notify an external service that the pod is starting. section 5.5.1
In a Pod manifest, place the ordered list under spec.initContainers; place regular containers under spec.containers. Each init container needs a name and an image. Keeping initialization in a separate image can avoid rebuilding the application image and lets the same setup be reused across applications. section 5.5.2 section 5.5.1
Wait for connectivity
A pod can run a short setup container, then a container that uses ping to test a configurable IP address, before starting its application and proxy containers. Apply its manifest with kubectl apply -f pod.kiada-init.yaml. Watch kubectl get pods -w and kubectl get events -w: the status advances through Init:0/2 and Init:1/2 before the regular containers run. section 5.5.2
Listing 9.5 Using an init container to initialize an emptyDir volume
apiVersion: v1
kind: Pod
metadata:
name: quiz
spec:
volumes:
- name: initdb #1
emptyDir: {} #1
- name: quiz-data
emptyDir: {}
initContainers:
- name: installer #2
image: luksa/quiz-initdb-script-installer:0.1 #2
volumeMounts: #2
- name: initdb #2
mountPath: /initdb.d #2
containers: #2
- name: quiz-api
image: luksa/quiz-api:0.1
ports:
- name: http
containerPort: 8080
- name: mongo
image: mongo
volumeMounts:
- name: quiz-data
mountPath: /data/db
- name: initdb #3
mountPath: /docker-entrypoint-initdb.d/ #3
readOnly: true #3
This manifest shows a practical shared-volume setup: an init container copies a database initialization script into an emptyDir volume, which the MongoDB container mounts when it starts. section 9.2.2
To inspect an init container, use kubectl logs POD -c CONTAINER while it runs or after it finishes. kubectl exec can enter one only while it is running—useful if initialization is taking too long. section 5.5.3
A failed init container may restart when the pod’s restart policy is Always or OnFailure. With Never, later containers do not start and the pod remains at Init:Error; delete and recreate the Pod object to retry. A container listed under initContainers with its own restartPolicy set to Always is a different case: it is a sidecar and is not expected to finish before the next container starts. section 6.4.1 section 6.4.4
