What Really Makes a Kubernetes Pod? Inside Its Isolation, Namespaces & Cgroups

When you first start using Kubernetes you learn that each Pod gets a unique IP and hostname, and containers in the same Pod can talk to each other via localhost. Soon you discover that each container has its own isolated filesystem and cannot see processes of the other containers, so a Pod is more like a group of containers sharing a network stack.

1. Exploring Containers

The OCI runtime spec does not limit containers to Linux containers, but in this article we focus on the traditional Linux implementation using namespaces and cgroups.

Setting up a playground

# cat > Vagrantfile <<EOF
# -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant.configure("2") do |config|
  config.vm.box = "debian/buster64"
  config.vm.hostname = "docker-host"
  config.vm.define "docker-host"
  config.vagrant.plugins = ['vagrant-vbguest']
  config.vm.provider "virtualbox" do |vb|
    vb.cpus = 2
    vb.memory = "2048"
  end
  config.vm.provision "shell", inline: <<-SHELL
    apt-get update
    apt-get install -y curl vim
  SHELL
end
EOF

Running a container:

$ docker run --name foo --rm -d --memory='512MB' --cpus='0.5' nginx

Exploring a container's namespaces

After starting a container you can list the isolation primitives created for its process:

# Look up the container in the process tree.
$ ps auxf
# Find the namespaces used by the process.
$ sudo lsns

The namespaces you will see are mnt (mount), uts (hostname/domain), ipc (inter‑process communication), pid (process IDs) and net (network stack).

Exploring a container's cgroups

Cgroups can be inspected via the virtual filesystem:

# Check cgroupfs for the container's main process.
$ cat /proc/${PID}/cgroup

2. Exploring Pods

Kubernetes Pods can be implemented by different CRI runtimes. When using a ContainerD/Runc runtime the Pod consists of a pause sandbox container plus the user containers.

Setting up a minikube playground

$ curl -sLS https://get.arkade.dev | sh
$ arkade get kubectl minikube
$ minikube start --driver virtualbox --container-runtime containerd

Apply a Pod manifest:

apiVersion: v1
kind: Pod
metadata:
  name: foo
spec:
  containers:
  - name: app
    image: docker.io/kennethreitz/httpbin
    ports:
    - containerPort: 80
    resources:
      limits:
        memory: "256Mi"
  - name: sidecar
    image: curlimages/curl
    command: ["/bin/sleep", "3650d"]
    resources:
      limits:
        memory: "128Mi"

Inspecting the Pod on the node shows three processes: the pause container, the httpbin container and the sidecar container. The httpbin and sidecar containers reuse the pause container's net, uts and ipc namespaces, which explains why containers in the same Pod can communicate via localhost and share hostname.

Pod namespaces

By default a Pod shares the network, IPC and PID namespaces among its containers. Setting shareProcessNamespace: true adds a shared PID namespace, and flags like hostIPC, hostNetwork and hostPID can make a container use the host's namespaces.

Pod cgroups

The cgroup hierarchy created by Kubernetes looks like:

kubepods
 └─burstable
    └─pod<unique-id>
       ├─pause
       ├─httpbin
       └─sidecar

Each container can have its own resource limits while sharing the same cgroup parent.

3. Building a Pod‑like Structure with Docker

Using Docker you can emulate a Pod by creating a shared cgroup and a sandbox container, then launching other containers with --network container:… and --ipc container:… to reuse the sandbox's namespaces.

# Create a parent cgroup
sudo cgcreate -g cpu,memory:/pod-foo
# Run a sandbox container
docker run -d --rm --name foo_sandbox --cgroup-parent /pod-foo --ipc 'shareable' alpine sleep infinity
# Run containers that share the sandbox's network and IPC
docker run -d --rm --name app --cgroup-parent /pod-foo \
  --network container:foo_sandbox --ipc container:foo_sandbox kennethreitz/httpbin
docker run -d --rm --name sidecar --cgroup-parent /pod-foo \
  --network container:foo_sandbox --ipc container:foo_sandbox curlimages/curl sleep 365d

These containers share the same net and ipc namespaces, mimicking a Kubernetes Pod, though sharing the uts namespace is not currently supported by Docker.

4. Summary

Containers and Pods both rely on Linux namespaces and cgroups, but a Pod is a higher‑level construct that groups containers on the same node, synchronises their lifecycles and deliberately reduces isolation to simplify inter‑container communication. This makes Pods behave more like lightweight VMs, enabling patterns such as sidecars and in‑Pod proxies.