At times we'll need to initialize our application before it actually runs, such as by preparing schema for the main application or loading data from another place. As it's difficult to predict how long the initialization could take, we can't simply rely on initialDelaySeconds to create a buffer for this preparation, so init containers come in handy here.

init containers are one or more containers that start prior to application containers and run one by one to completion in order. If any container fails, it's subject to the restartPolicy of a pod and starts over again until all containers are exited with code 0. Defining init containers is similar to defining regular containers:

...
spec:
  containers:
  - name: my-app
    image: <my-app>
  initContainers:
  - name: init-my-app
    image: <init-my-app>
...

They only differ in the following respects:

• init containers don't have readiness probes as they run to completion.
• The port defined in init containers won't be captured by the service in front of the pod.

• The request limit of resources are calculated with max(sum(regular containers), and max(init containers)), which means if one of the init containers sets a higher resource limit than other init containers, as well as the sum of the resource limits of all regular containers, Kubernetes schedules the pod according to the init container's resource limit.

The usefulness of init containers is more than blocking the application containers. For instance, we can utilize an init container to configure an image by sharing an emptyDir volume with init containers and application containers, instead of building another image that only runs awk/sed on the base image. Also, it grants us the flexibility to use different images for initialization tasks and the main application.