Containers and Orchestration
What this domain tests
Containers and Orchestration tests image construction and Kubernetes operations: layers, multi-stage builds, immutable tags, probes, resource management, and deployment strategies.
Core rules and concepts
- Images are built from layers. Order Dockerfile instructions so rarely changing layers, such as dependencies, precede application code to maximize cache reuse.
- Use multi-stage builds to keep compilers and build tools out of the runtime image, and run as a non-root user.
- Tag images with immutable versions or digests, never rely on latest in production.
- Kubernetes: a Pod is the scheduling unit; a Deployment manages ReplicaSets and rolling updates; a Service provides stable networking.
- Readiness probes control traffic; liveness probes restart containers. A too-aggressive liveness probe turns a slow start into a restart loop.
- Set requests and limits. Requests drive scheduling; limits cap usage and can cause OOM kills or CPU throttling.
- Store state outside containers; treat container filesystems as ephemeral.
Worked example
A new pod enters CrashLoopBackOff immediately after deploy, though it works locally. Reasoning: check events and previous logs first. If the app needs 60 seconds to warm up and the liveness probe fires after 10 seconds, Kubernetes kills it repeatedly. The fix is a startup probe or a longer initial delay, plus a readiness probe so traffic waits. Raising the liveness threshold without diagnosis only hides startup behavior.
Traps that cost marks
- Confusing readiness and liveness, causing traffic to hit unready pods or healthy pods to restart.
- Deploying without resource requests, leading to noisy-neighbor eviction.
- Baking environment-specific configuration into the image.
- Assuming a running container is a durable server.
- Using latest in production and losing reproducible rollback.