← Problem Library
K8s L4 K8S 1222 · 17 min

Init container completes but the app still crashes because it wrote config into a path the main container never mounts

Bootstrap looks successful, yet the runtime container fails because the prepared data lives on a volume path the application container does not actually see.

K8sPlatform ReliabilityLevel 4Pro17 min
Scenario

An init container creates generated config successfully and the app still starts without it.

What to check first
  • Identify the primary failure signal in the Shared Volume Assumption scenario.
  • Separate visible symptoms from the underlying technical dependency.
  • Describe the safest recovery path and the follow-up prevention work.
Checking checklist
  1. Summarize the current impact and the last known change.
  2. Collect direct evidence from logs, runtime state, and configuration before changing anything.
  3. Separate immediate recovery from permanent prevention work.
Recovery and prevention

Validate the exact shared volume path between init and main container before changing the image.

Questions worth viewing together
What should you verify first when Init container completes but the app still crashes appears?

Community-field Kubernetes startup problem inspired by Stack Overflow patterns where init containers wrote config to paths the app container did not mount. A completed init step proves only that it wrote somewhere, not that the app sees the same path.

What usually causes Init container completes but the app still crashes in production?

Teams often blame the main app parsing logic when the file was never on the shared mount.

What should you document after resolving Init container completes but the app still crashes?

Init-container success is meaningless if the volume contract with the main container is wrong.