Introduction
If you’ve been working with containers like Docker or Kubernetes, you’ve probably heard terms like “namespaces” and “cgroups” thrown around. But what are these technologies exactly, and why should you care about them?
Think of containers as special apartments in a large building. Each apartment needs its own private space and a fair share of building resources like electricity and water. In the container world, Linux namespaces create these private spaces, while control groups (cgroups) manage the resource allocation.
In this post, I’ll break down these concepts in plain English and show you why they’re so crucial for modern containerization. No heavy technical jargon — just clear explanations and simple examples to help you understand how your containers work under the hood.
What Are Container Namespaces?
Namespaces are Linux’s way of creating isolated workspaces for your processes. They answer the question: “What can this process see?”
Imagine you’re in a room with one-way mirrors — you can only see what’s in your room, not outside. That’s essentially what a namespace does for a containerized process.
Figure 1: Linux Namespaces create isolation between containers by giving each its view of system resources
Why Are Namespaces Needed?
Without namespaces, containers would be like having roommates with no boundaries — every process could see and potentially mess with every other process on the host. That would be:
- Insecure: A compromised container could attack the host or other containers
- Confusing: Processes would see thousands of unrelated processes
- Impractical: Port conflicts, file system conflicts, and many other problems would make containers nearly impossible to use
Types of Namespaces and Their Real-World Examples
Let’s look at the main types of namespaces and how they help in everyday container usage:
1. Process ID (PID) Namespaces
What it does: Creates a separate process tree with its own numbering.
Simple example: When you run ps aux inside a container, you’ll only see the processes in that container, not the hundreds or thousands of processes running on the host. Your container’s main process thinks it’s “PID 1” (like the init process on a regular Linux system), even though it might actually be process 34567 on the host.
# On host:
$ ps aux | wc -l
213 # 213 processes visible
# In container:
$ ps aux | wc -l
7 # Only 7 processes visible inside container
2. Network (NET) Namespaces
What it does: Gives each container its own network stack.
Simple example: You can run multiple web servers on port 80 in different containers, and they won’t conflict. Each container has its own IP address, routing table, and network interfaces.
# Container 1
$ nc -l -p 80 # Listening on port 80
# Container 2 (simultaneously)
$ nc -l -p 80 # Also listening on port 80, no conflict!
3. Mount (MNT) Namespaces
What it does: Gives each container its own file system view.
Simple example: One container sees /app as containing a Node.js application, while another container sees /app as containing a Python application. They’re actually different directories on the host, but both containers think they’re working with /app.
# Container 1
$ ls /app
package.json node_modules index.js
# Container 2
$ ls /app
requirements.txt app.py venv
4. Interprocess Communication (IPC) Namespaces
What it does: Isolates shared memory, semaphores, and message queues.
Simple example: A database container using shared memory for caching won’t accidentally interact with another container’s shared memory segments.
5. UTS Namespaces
What it does: Allows each container to have its own hostname.
Simple example: You can run three containers named “web1”, “web2”, and “web3”, and each will see its own hostname when running the hostname command.
# In container 1
$ hostname
web1
# In container 2
$ hostname
web2
6. User Namespaces
What it does: Maps users between container and host.
Simple example: A process can run as root (UID 0) inside the container but actually be mapped to an unprivileged user (like UID 100000) on the host. This adds security because even if someone “breaks out” of the container with root privileges, they’d only have regular user privileges on the host.
As shown in Figure 1, each container (Web Frontend, API Service, and Batch Job) has its own set of namespaces, creating the illusion that each container is running on its own dedicated system.
What Are Control Groups (cgroups)?
If namespaces are about isolation (what a container can see), control groups (cgroups) are about limitation (what a container can use). They answer the question: “How much resources can this process consume?”
Think of cgroups as resource quotas or allowances for your containers.
Figure 2: Control Groups (cgroups) limit how much of each resource type containers can use
Why Are Control Groups Needed?
Without cgroups, containers would be like roommates with no limits on shared resources:
- One container could hog all the CPU, starving others
- A container with a memory leak could bring down the entire system
- A single process could saturate your network or disk I/O
Cgroups prevent the “noisy neighbor” problem, where one badly behaved container impacts everything else running on the same host.
Types of Resource Controls and Their Real-World Examples
Let’s explore how cgroups limit different resources with practical examples:
1. CPU Time
What it does: Limits how much CPU time a container can use.
Simple example: You have a CPU-intensive batch job that would normally use 100% of the CPU, but you want to ensure it doesn’t slow down other applications. You set a CPU limit of 30%, and the kernel ensures the container never uses more than that, regardless of how much CPU is available.
# Setting a container to use at most 0.3 CPU cores
$ docker run --cpus=0.3 cpu-intensive-app
2. Memory
What it does: Restricts RAM usage and defines what happens when limits are reached.
Simple example: A web app with a memory leak might normally grow until it consumes all available RAM. With memory limits, you could cap it at 500MB, ensuring it gets terminated if it exceeds that limit, rather than slowing down the entire server.
# Limiting a container to 500MB of RAM
$ docker run --memory=500m memory-hungry-app
In real life, this can save your production environment during traffic spikes or when bugs cause memory leaks.
3. Network Bandwidth
What it does: Controls data transfer rates for containers.
Simple example: You have a backup process that could saturate your network connection. By setting bandwidth limits, you ensure it only uses up to 10MB/s, leaving bandwidth for other services.
4. Disk I/O
What it does: Limits read/write operations or bytes per second.
Simple example: A logging service that writes intensively to disk gets limited to 50MB/s of write throughput, preventing it from slowing down database operations that share the same physical disks.
# Limiting write operations for a container
$ docker run --device-write-bps /dev/sda:50mb intensive-io-app
As shown in Figure 2, the Web Frontend, API Service, and Batch Job containers are allocated different portions of the available system resources. This ensures that critical services (like the customer-facing frontend) get priority access to resources.
How Namespaces and cgroups Work Together
Namespaces and cgroups complement each other to make containers work:
- Namespaces create the illusion of a separate machine
- Cgroups ensure resources are divided fairly
Together, they solve the fundamental container challenge: running isolated workloads efficiently on shared infrastructure.
Figure 3: How namespaces and cgroups work together to create isolated, resource-controlled containers
Let’s see how they work together with a real-world example:
Microservices Example
Imagine you’re running three microservices on a single server:
- A web frontend
- An API service
- A batch processing job
With namespaces:
- Each service thinks it’s running on its own machine
- Each has its own process tree, network stack, and file system view
- They can all bind to the same ports without conflicts
- One service can’t see or access processes in the others
With cgroups:
- The web frontend (customer-facing) gets priority: 50% of CPU and 4GB RAM
- The API service gets 30% of CPU and 2GB RAM
- The batch job (less urgent) gets 20% of CPU and 1GB RAM
- If the batch job tries to use more resources, it’s automatically throttled
The result? All three services coexist on the same hardware, with proper isolation and resource allocation. If the batch job has a bug and tries to consume all CPU, it simply can’t — the other services continue running normally.
As illustrated in Figure 3, each container has both namespace isolation (what it can see) and resource limits (what it can use), allowing multiple containers to run efficiently on the same host without interfering with each other.
Why This Matters for Developers and Ops Teams
Even if you’re not directly configuring namespaces and cgroups (container engines like Docker do this for you), understanding these concepts helps you:
- Debug issues — When containers behave unexpectedly, knowledge of the underlying isolation helps troubleshoot
- Optimize resources — Set appropriate limits for your applications
- Improve security — Understand isolation boundaries and potential risks
- Design better systems — Architect your containerized applications with resource constraints in mind
Conclusion
Container namespaces and control groups are the unsung heroes of modern containerization. Namespaces provide the isolation that makes containers lightweight and secure, while cgroups ensure resources are used fairly and efficiently.
By understanding these fundamental technologies, you gain insight into how your containerized applications actually work. You don’t need to be a kernel expert to use this knowledge — just being aware of these concepts can help you write better container configurations, troubleshoot issues more effectively, and make better decisions about container orchestration.
The next time you run a Docker container or deploy to Kubernetes, take a moment to appreciate the elegant isolation and resource management happening behind the scenes. These technologies transformed how we deploy software, enabling the cloud-native revolution we see today.
What aspects of container isolation would you like to learn more about? Let me know in the comments!
Follow subbutechops.com for more practical guides and technical deep-dives into containerization and DevOps practices!
