Many applications start with an initialization logic. Constructors in a OOP are used to "prepare" the object for it's life-cycle of tasks. It could be set-up connections, handlers, seed-data, set initial/default values, state configurations etc
Point to note is that initialization happens only once (and obviously at the beginning). The purpose of this pattern is to decouple initialization logic from the main business logic. This allows you to make changes to how the object “starts” without affecting how it “works”.
Kubernetes pods have provision to create multiple such init containers to help prepare the main container for it's operation. An init container is the one that starts and executes before other containers in the same Pod. It’s purpose is to perform initialization logic for the main application hosted on the Pod. For example, create the necessary user accounts, perform database migrations, create database schemas and so on.
- They should be simple and concise => finish fast
- If there are >1 init containers, all of them are executed sequentially.
- An init container is not executed unless it's previous init container as per the sequence is done and successful
- They are restarted when they fail => they should be idempotent
- Init containers resource limits (if large) can adversely affect the pod scheduling