container into any Pod that doesn’t have one already. In contrast, the Init Container pattern discussed in this chapter is something that activates and performs its respon‐ sibilities during startup of the Pod. In the end, the most significant difference is that init containers is for developers deploying on Kubernetes, whereas the techniques described here help administrators control and manage the container initialization process. 

## Discussion 

So why separate containers in a Pod into two groups? Why not just use an application container in a Pod for initialization if required? The answer is that these two groups of containers have different lifecycles, purposes, and even authors in some cases. 

Having init containers run before application containers, and more importantly, hav‐ ing init containers run in stages that progress only when the current init container completes successfully, means you can be sure at every step of the initialization that the previous step has completed successfully, and you can progress to the next stage. Application containers, in contrast, run in parallel and do not provide the same guar‐ antees as init containers. With this distinction in hand, we can create containers focused on a single initialization or application-focused task, and organize them in Pods. 

## More Information 

• Init Container Example 

• Init Containers 

• Configuring Pod Initialization 

• The Initializer Pattern in JavaScript 

• Object Initialization in Swift 

• Using Admission Controllers 

• Dynamic Admission Control 

• How Kubernetes Initializers Work 

• Pod Preset 

• Inject Information into Pods Using a PodPreset 

• Kubernetes Initializer Tutorial 

