Init containers, sharing, and persistence | CKAD: Kubernetes applications in production

Concept and mechanism

A regular init container runs before application containers and must finish successfully. It suits finite preparation, such as generating configuration, with safe retries. An infinite process in a regular init blocks startup; a sidecar has another role and its own rules. In a multi-container Pod, make shared volumes and mount paths explicit. Sharing a Pod does not automatically make every image directory common. Observe the correct container’s status and logs to distinguish failed preparation from an application failure.

Guided application

emptyDir follows the Pod lifecycle and can retain files when a container restarts within that Pod. Removing the Pod loses the data. It suits caching and temporary sharing, not receipt archiving. For persistence, assess PVCs, StorageClasses, topology, and supported access modes. A mount mode implements neither writer coordination nor backup. In a service with several replicas, identify who writes each object and how to restore consistency after failure instead of assuming a shared volume solves application design.

IN PRACTICE

An init generates /config/runtime.json in an emptyDir also mounted by the application. Payment receipts require durable storage and separately validated recovery.

Common pitfalls

Expecting readiness to fix a failed init; using emptyDir as an archive; confusing persistence with safe concurrent writes.

Related topics: Deployments and recovery · Application observability and maintenance

Take this idea with you

Plan startup, temporary sharing, and durability separately.

Create account

Reference: Init containers · CKAD Kubernetes v1.35