How do containers achieve isolation if they share the host OS kernel?
Fast recall
Quick revision
Core answer
Interview-ready guide
Interview answer
Containers isolate processes by combining several kernel controls. Namespaces give a process a restricted view of resources such as process IDs, mounts, networking, host names, users, and IPC. Cgroups account for and limit resources such as CPU and memory. Capabilities, seccomp, AppArmor or SELinux, read-only filesystems, and user namespaces can further reduce privilege.
For example, docker run --memory=512m --cpus=1 --read-only ... requests a memory/CPU boundary and a read-only root filesystem, while the runtime creates namespace isolation. The exact namespaces and enforcement depend on platform and configuration.
All Linux containers on that host environment still use the same kernel. A kernel or runtime vulnerability, excessive capability, privileged mode, or exposed socket can weaken the boundary. Therefore container security combines least privilege, resource limits, trusted images, patching, and workload separation; it is not simply 'namespaces make each container see only itself.'
How do containers achieve isolation if they share the host OS kernel
Direct Answer
Linux containers combine kernel mechanisms: namespaces isolate views such as processes, mounts, users, and networking; cgroups account for and limit resources; capabilities, seccomp, and security modules can reduce privileges. Containers still share a kernel, so configuration and kernel security matter and the boundary differs from a VM.
Code Example
// Run a Spring Boot container with resource limits and namespace isolation
// This demonstrates cgroups (memory/CPU limits) and implied namespace isolation
docker run -d \
--name order-service \
--memory="512m" \
--cpus="1.5" \
-p 8080:8080 \
order-service:latest
// Inside the container, check what processes are visible
docker exec order-service ps aux
// Output shows ONLY container processes:
// PID 1: java -jar order-service.jar
// PID 42: ps aux
// The container can't see host processes or other containers
// From the host, the same Java process has a different PID
ps aux | grep order-service
// Shows: user 12847 java -jar order-service.jar
// The host sees it as a regular process, but namespaces give it an isolated view
// The memory and cpus flags use cgroups under the hood
// Kernel enforces these limits; container can't exceed 512MB even if host has 16GB
Common Mistakes & Pitfalls
- Thinking isolation is magic: Freshers often say containers are isolated without realizing it's specific kernel features doing the work. When asked how, they can't explain the mechanism. Understanding namespaces and cgroups shows you actually know what's happening under the hood.
- Assuming complete isolation: Not realizing that while containers have separate process trees, they still share the kernel. A kernel panic or exploit affects all containers on that host. VMs don't have this issue because each has its own kernel.
- Ignoring resource limits: Running containers without setting memory and CPU limits via cgroups. One container can then consume all host resources, starving others. In production, you always set limits.
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.