Before the main container of a municipal records API starts on OKE, the team must run a one-shot schema migration against the database. Which Pod construct should they use?

Before a municipal records API serves traffic on OKE, a one-shot schema migration should run in an init container that completes successfully before any application container starts. Init containers run sequentially to completion as part of Pod startup; only then do the main containers begin. That ordering guarantees the database schema is ready when the records API process starts, without turning migration into a permanently running peer or into a health-check side effect.

A second long-running sidecar that merely shares the migration script fails by concept because sidecars stay alive beside the app; they are for ongoing helpers (proxies, log shippers), not one-shot setup that must finish first. A CronJob that restarts the Deployment every night fails because CronJobs schedule recurring Jobs—they do not model “run once before this Pod’s main container starts,” and nightly restarts are the wrong lifecycle for a schema gate. A readiness probe that shells out to the migration tool on every check fails because readiness probes must be cheap and repeatable; embedding heavy one-time migrations in probes creates flapping, duplicate migrations, and probes that never settle.

Exam caveat: init containers still need correct image, network path to the database, and credentials (usually via Secret), and failed init containers block Pod readiness indefinitely until fixed. Operational check: deploy a canary Pod, watch kubectl describe pod for init container Completed status before the app container starts, confirm migration logs once, then verify the main container serves only after schema version checks pass.