Docker & OCI8 min read•October 2026•Kernelry Staff

Docker Containerization and Multi-Stage Build Scenarios

Production container engineering demands deep knowledge beyond writing basic Dockerfiles. Senior DevOps teams look for expertise in minimizing image layers, leveraging BuildKit cache mounts, locking down non-root container runtimes, configuring bridge and host networking, and inspecting Linux cgroup and namespace boundaries.

Architecture Blueprint

Docker Multi-Stage Build and Layer Cache Hierarchy

How BuildKit caches independent build stages and extracts minimal binary artifacts into an unprivileged scratch or distroless runtime image.

The Core Concept

Docker isolates software applications inside lightweight containers that share the underlying Linux kernel. By packaging code, runtime libraries, and environment settings into reproducible immutable images, Docker ensures consistent behavior across developer laptops and production servers.

Key Rules of Thumb for Production Systems

•Order Dockerfile instructions from least frequently changed to most frequently changed to maximize cache reuse.

•Use multi-stage builds to strip build-time compilers and dev-dependencies from final production runtime images.

•Always enforce non-root user execution (USER 10001) to mitigate potential container breakout attacks.

•Understand the role of the Linux OOM killer when container memory limits are exceeded.

Why Production Systems Demand This Depth

Poorly constructed Docker images inflate deployment pipelines with gigabytes of bloat, widen the blast radius of a container escape by running as root or with --privileged, and fail unpredictably under production memory constraints. Knowing how to profile layer cache misses and tune OCI container flags directly impacts platform reliability.

Common Diagnostic Pitfalls

•Using the latest tag in production base images, leading to non-reproducible deployments.
•Placing frequently changing application source code above dependency installation commands in Dockerfiles.
•Running containers as root without dropping Linux capabilities (cap-drop ALL).
•Mounting the host Docker socket (/var/run/docker.sock) inside untrusted build containers.

Best Practices for Scenario Drills

•Explain how multi-stage builds cleanly separate build toolchains (e.g., Maven, Go compiler) from the runtime image.
•Discuss BuildKit features like --mount=type=cache and --mount=type=secret to avoid leaking API credentials into image layers.
•Describe how Docker handles PID 1 signals (SIGTERM vs SIGKILL) and why init systems like tini prevent zombie process accumulation.

Worked Production Scenarios

Study real-world outage patterns, diagnostic trees, and clarifying questions.

Optimizing a Bloated Production Container Image

Difficulty: mid

Scenario Prompt:

“A team reports that their Node.js production image takes 4 minutes to download and deploy because it weighs 1.8 GB. Security scanners also flag dozens of high-severity CVEs from build packages. How do you re-architect the Dockerfile?”

Substantive Technical Concepts to Hit:

Multi-Stage Build Separation

Use a builder stage with npm install to compile dependencies, then copy only production node_modules and built artifacts to a clean runtime stage.

Minimal Base Image Selection

Replace heavy full-OS images (node:20) with lightweight Alpine, distroless, or slim Debian variants.

Layer Cache Ordering

Copy package.json and lockfiles first, run dependency installation, and copy application source code in subsequent layers to preserve caching.

Unprivileged Runtime User

Add a dedicated non-root application user and switch using USER node before the CMD instruction.

Senior Clarifying Questions to Investigate:

Does the application require native C++ addon compilation that Alpine musl libc might complicate?
Are we building images in CI with access to a shared remote registry cache or local BuildKit cache?
What vulnerability scanning thresholds (e.g., Trivy or Grype) must the final image pass?

A Java Container Is OOMKilled While Heap Metrics Look Fine

Difficulty: senior

Scenario Prompt:

“A Java service runs with a 1 GiB memory limit and keeps restarting with exit code 137. The JVM heap dashboard never shows more than 600 MB in use. Why is the container being killed, and how do you fix it?”

Substantive Technical Concepts to Hit:

Exit Code 137 and the cgroup OOM Killer

137 is 128 + 9: the process received SIGKILL. docker inspect or kubectl describe pod shows OOMKilled: true when the kernel killed it for exceeding the cgroup memory limit, which rules out an application crash.

Memory Outside the Heap

The limit covers the whole process, not just the heap. Metaspace, thread stacks, the JIT code cache, direct byte buffers and native libraries all count, so a 600 MB heap can still push the container past 1 GiB.

Container-Aware JVM Sizing

Size the heap as a share of the limit with -XX:MaxRAMPercentage (for example 60 to 75) instead of a fixed -Xmx close to the limit, and leave room for off-heap memory. Older JDK builds that only understand cgroup v1 ignore the limit on cgroup v2 hosts.

Measuring Native Memory

Run with -XX:NativeMemoryTracking=summary in staging and compare jcmd VM.native_memory output with the container working set to see which area is growing.

Senior Clarifying Questions to Investigate:

Which JDK version is in the image, and does it read the cgroup v2 memory limit on these hosts?
Is the growth steady (a native leak) or tied to load, such as one thread stack per request?
Do the memory request and limit match, or is the pod also exposed to node-level eviction?

Interactive Scenario Drills

That's where we come in.

Explaining architectural trade-offs under time constraints is very different from reading about them.

Kernelry helps you rehearse technical questions, evidence-led debugging, safe next steps, and the clear communication teams expect. The drills adapt to your answer, so you practice the reasoning rather than memorize a company-specific script. During early access, free accounts include ten daily scenarios across our mixed question pool, with no credit card required.

Start Today's Free Drill

Back to All Blog Posts