initContainers for Infrastructure containers

1. Origin of initContainers

initContainers was introduced in Kubenetes 1.3 to configure Init containers that run and exits before the main containers start.

Init containers were intended to perform one-time work such as:

• Setting up environment variables
• Preparing configuration files
• Checking dependencies before app start
• Etc.

Unlike regular containers, they start and finish in order. And only after they finish, the regular containers could start

Take example of 2 init containers and one regular container below:

apiVersion: v1
kind: Pod
spec:
  initContainers:
  - name: init1
    image: init1:latest
  - name: init2
    image: init2:latest
  containers:
  - name: app
    image: app:latest

Here we have init1 container starts and finishes. Then init2 container starts and finishes. Then app container could start.

2. Native Sidecar containers

Kubenetes 1.28 introduced sidecar containers. Their purposes is to replace the traditional sidecar container that is declared as regular container.

At configuration, sidecar container is Init container with restart: always. However, the only common behavior between Init container and native sidecar container is the deterministic container start up ordering.

Unlike Init containers, native sidecar containers will start before regular containers and finish after them.

Example:

apiVersion: v1
kind: Pod
spec:
  initContainers:
  - name: init1
    image: init1:latest
  - name: init2
    image: init2:latest
  - name: sidecar1
    image: sidecar1:latest
    restartPolicy: Always
    startupProbe:...
    readinessProbe:..
  - name: sidecar2
    image: sidecar2:latest
    restartPolicy: Always
    startupProbe:...
    readinessProbeu:..
  containers:
  - name: app
    image: app:latest

The execution order is:

• init1 container starts and exits
• init2 container starts and exits
• sidecar1 and sidecar2 containers start concurrently
• app container starts after both sidecar1 and sidecar2 are ready
• app container finishes
• sidecar1 and sidecar2 exit concurrently

3. Infrasturcture containers

The new native sidecar container with different behavior than Init containers. This adds more capacities for existed initContainers in configuration for Kubenetes Pod.

The name initContainers is not a good fit for sidecar containers as they typically do more than initialization. The better name can be “infrastructure” containers. The current idea is to implement sidecars as a part of initContainers and if this introduces too much trouble, the new collection name may replace the old collection name in future.

KEP-753

4. Conclusion

Init containers have long served their purpose as companion containers that help to prepare for main containers to start. Native Sidecar containers expand beyond this model and behave much different than the true Init containers. As a result, initContainers become configuration part to declare new generalized Infrastructure container.