Comparison
Init containervsSidecar
Init container
a throwaway container runs the migration, finishes, and only then does the application container start.
A container that runs to completion before the main containers start, in order, used for setup: waiting on a dependency, running a schema migration, fetching configuration. The distinction from a sidecar is temporal — an init container finishes and the app then runs, a sidecar runs beside it — and confusing the two produces either a pod that never starts or a migration racing the application. If an init container fails, the pod restarts and runs it again, so it must be safe to repeat.
Full entry →Sidecar
a second container next to your application handles TLS, logging or metrics, and your code was never changed.
A container that runs alongside the application in the same pod, providing a cross-cutting capability out of process. It is the mechanism behind service meshes, log shippers and secret-fetching agents, and its appeal is that a platform team can ship a capability to every service without touching anyone's code. The costs are equally real: it doubles the container count, it consumes requests and limits of its own, and startup and shutdown ordering between the two becomes your problem.
Full entry →