8.13 Kubernetes Init Container Usage
Kubernetes Init Containers ensure pods start correctly by running setup tasks before the main application containers launch.
Kubernetes Init Container Usage is the practice of running one or more specialized containers to completion before a Pod's main application containers are started, in order to perform setup, validation, or dependency-waiting tasks that must finish before the primary workload begins.
Fundamental Behavior
Sequential Execution
Init containers defined in a Pod's spec.initContainers list run one at a time, in the order they are listed. Each init container must exit successfully before the next one starts, and all init containers must complete before any app container in the Pod is started.
Failure Handling
If an init container fails, the kubelet retries it according to the Pod's restartPolicy. A Pod is not considered "Ready" until every init container has exited successfully, so a persistently failing init container will keep the entire Pod out of service indefinitely.
Isolation from App Containers
Init containers run in the same network namespace and can share volumes with app containers, but they do not run concurrently with them. This makes them well suited for tasks that must complete before the application is exposed to traffic, such as writing a configuration file that the main container then reads.
Common Use Cases
Waiting for Dependencies
An init container can poll a database, message queue, or upstream service until it becomes reachable, preventing the main application from starting and immediately failing its own readiness checks because a dependency was not yet available.
Cloning or Fetching Data
An init container can clone a Git repository, download a data set, or pull configuration from a remote source into a shared emptyDir volume, which the main container then mounts and reads at startup.
Running Setup Scripts
Init containers can run migrations, permission fixes, or file system preparation, such as chown-ing a mounted volume so the main container can run as a non-root user without permission errors.
Security Separation
Because an init container can use a different image than the main application, sensitive tools such as Git credentials or a database migration client can be isolated in the init container's image and excluded from the final application image, reducing the main container's attack surface.
Configuration Details
Resource Requests and Limits
Init containers can define their own CPU and memory requests and limits, separate from app containers. Kubernetes computes the effective Pod-level resource request as the highest of either the sum of all app container requests or the largest single init container request, since init containers run sequentially and never simultaneously with each other or with app containers.
Shared Volumes
A volume declared at the Pod level can be mounted by both an init container and an app container. This is the primary mechanism for passing data, such as downloaded files or generated configuration, from the setup phase into the running application.
Probes Do Not Apply
Readiness, liveness, and startup probes are not applicable to init containers, since their success is defined purely by process exit code rather than by an ongoing health check.