Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

10 — init containers

A Deployment with two init containers that run before the main nginx container starts. The first blocks pod startup until the database is reachable; the second applies a schema migration. Both run sequentially, in the order their map keys sort alphabetically.

What this shows

  • Per-workload initContainers declared as a map keyed by container name.
  • The 01-, 02- prefix convention for run order — same idea as jobGroups[*].tasks (Kubernetes runs init containers sequentially in declared order; the chart sorts the map alphabetically before emitting).
  • Per-init container image override (the migration init uses a different image from the main container).
  • envSecrets on an init container — root envSecrets are merged in automatically; the per-init list adds workload-specific Secrets on top.

Delta vs. previous examples

01-minimal/ shows the simplest case: one container, one Service. This example adds two init containers ahead of the main container without changing anything else. The same initContainers map is also accepted under statefulSets.<name> with identical semantics.

Files

FilePurpose
values.yamlChart values for this scenario.
argocd/application.yamlArgo CD Application, single source.
argocd/application-multisource.yamlArgo CD Application with spec.sources[] — chart from OCI, values from a git repo via $values.
flux/ocirepository.yamlFlux OCIRepository pointing at the OCI chart.
flux/helmrelease.yamlFlux HelmRelease consuming the OCIRepository.
helm/install.shPlain helm upgrade --install command.

Try it

Pick any one of:

  • Helm CLI: bash helm/install.sh
  • Argo CD: kubectl apply -f argocd/application.yaml -n argocd
  • Flux: kubectl apply -f flux/

Heads-up

  • Reloader does not re-run init containers on config changes. Init containers run only on Pod creation. When a watched ConfigMap or Secret changes, Reloader rolls the workload — a fresh Pod starts, and the init containers run again as part of that fresh start. If your migration is idempotent (and it should be), this is exactly what you want.
  • volumeMounts.<initContainerName> at root level is NOT inherited. Init containers behave like sidecars here — declare any mounts they need inline under deployments.<name>.initContainers.<initName>.volumeMounts. Auto-mounted ConfigMaps (those declared under configMaps.<name> with a mountPath) DO mount into init containers, unless disabled via inherit.configMapMount.