Skip to content

SYSTEM Cited by 1 source

Kubernetes init containers

Init containers are a Kubernetes primitive that lets a pod run one or more containers sequentially before the main container(s) start. Each init container must run to completion in order, after which the main container(s) begin. They share volumes with the main container but run to a separate lifecycle.

Canonical uses: setup tasks (download config, run migrations, wait for dependencies) that must complete before the workload container starts.

Used for upgrade sequencing

A less-common-but-powerful use is sequencing two simultaneous changes (e.g. IP + version) that must be observable to distributed-protocol peers as two distinct events rather than one combined event. The init container performs change A under the old version, exits, and the main container then starts with change B under the new version.

Seen in

  • sources/2026-04-07-yelp-zero-downtime-cassandra-4x-upgrade — canonical wiki Seen-in for the sequencing-two-changes idiom. Yelp's Cassandra-on-Kubernetes operator gets a new pod IP on every restart, and Cassandra 3.11 gossip couldn't negotiate a simultaneous IP + version change (CASSANDRA-19244). Yelp's fix: an init container first runs 3.11 Cassandra on the new IP and gossips the IP change into the ring; once gossip has observed the new IP under the old version, the init container exits and the main container starts as 4.1 on the now-stable IP — gossip then observes a pure version flip. Presented at KubeCon 2025 ("Upgrading Cassandra on Kubernetes").
Last updated · 476 distilled / 1,218 read