Memory hook: One Pod shares a lifecycle; one image should have one clear purpose.
Must remember
A container image packages filesystem layers and startup metadata. Build from a controlled base, copy only required files, use multi-stage builds to leave compilers behind, and exclude credentials/build context secrets. Tags can move; a digest identifies specific content. Understand Dockerfile ENTRYPOINT and CMD, then how Kubernetes command and args override them.
Containers in a Pod share network identity and can share declared volumes, but their root filesystems are separate. Use an init container for prerequisites that must finish before normal application startup. A sidecar supplies a companion capability such as a proxy or log shipper; an adapter normalizes output and an ambassador mediates access to another service. Do not put unrelated applications in one Pod merely to share a node.
Native sidecars use restartable init-container behavior in supported versions. Their ordering/lifecycle differs from ordinary init containers and long-running app containers, so inspect the target API documentation. A one-shot init command that never exits can block startup indefinitely.
Kubernetes does not automatically interpret command/args as a shell script. Pipes, redirects and chained commands require an explicitly invoked shell, and the image must contain that shell. Native sidecars specify restartPolicy: Always on an init container; ordinary init containers must finish before the next starts. Do not confuse this per-container setting with the Pod's restart policy.
Choose a Deployment for interchangeable replicas, StatefulSet for stable identity/storage patterns, DaemonSet for node-local agents and Job/CronJob for finite/scheduled work. A Job's retry and completion settings do not make an external payment operation idempotent. CronJob concurrency and missed-run behavior need deliberate configuration.
For batch work, completions is the success target, parallelism bounds concurrently active Pods, and backoffLimit limits retry failures. CronJob concurrencyPolicy chooses Allow, Forbid or Replace for Jobs from that CronJob; startingDeadlineSeconds bounds how late a missed run may start. These controls do not provide exactly-once business processing.
Drill: explain how a shared emptyDir passes a generated configuration from an init container to an application, why it survives a container restart, and why deleting the Pod removes it. Then inspect the actual image, command, args and events when the app fails to start.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Prepare a file before app startup | Init container and a shared volume. |
| Helper must run alongside the app | A suitable sidecar lifecycle. |
| Repeatable image deployment | Pin a reviewed digest and retain provenance. |
Traps
- A Pod shares a network namespace, not automatically every filesystem path.
- Image tags are not immutable identifiers.
Active recall
1. Kubernetes command maps to which image behavior?
It overrides the image entrypoint; args supplies/overrides its arguments.
2. Why use multi-stage builds?
To build with needed tools while keeping the final runtime image smaller.
3. Why can init block the whole Pod?
Normal startup waits for ordinary init containers to complete successfully.
4. What shares data between containers?
An explicitly mounted common volume, not their separate root filesystems.
5. Why must batch handlers tolerate retries?
Jobs and infrastructure can retry after partial completion.