CHAPTER 14 Init Container Problem Init Containers  enable separation of concerns by providing a separate lifecycle for initialization-related tasks distinct from the main application containers. In this chap‐ ter, we look closely at this fundamental Kubernetes concept that is used in many other patterns when initialization logic is required. Initialization is a widespread concern in many programming languages. Some lan‐ guages have it covered as part of the language, and some use naming conventions and patterns to indicate a construct as the initializer. For example, in the Java program‐ ming language, to instantiate an object that requires some setup, we use the construc‐ tor (or static blocks for fancier use cases). Constructors are guaranteed to run as the first thing within the object, and they are guaranteed to run only once by the manag‐ ing runtime (this is just an example; we don’t go into detail here on the different lan‐ guages and corner cases). Moreover, we can use the constructor to validate preconditions such as mandatory parameters. We also use constructors to initialize the instance fields with incoming arguments or default values. Init Containers  are similar, but at Pod level rather than class level. So if you have one or more containers in a Pod that represent your main application, these containers may have prerequisites before starting up. These may include setting up special per‐ missions on the filesystem, database schema setup, or application seed data installa‐ tion. Also, this initializing logic may require tools and libraries that cannot be included in the application image. For security reasons, the application image may not have permissions to perform the initializing activities. Alternatively, you may want to delay the startup of your application until an external dependency is satisfied. For all these kinds of use cases, Kubernetes uses init containers as implementation of 125