Understanding Container Isolation Inside a Kubernetes Pod

Written by

in

,

I had a few questions about containers running inside the same Kubernetes Pod:

  • Can they see each other?
  • Do they share the same network?
  • Do they share the same filesystem?
  • What do the process IDs look like inside each container?

To verify these behaviors, I created a Pod with three containers and checked them one by one.

Experiment Setup

apiVersion: v1
kind: Pod
metadata:
  name: three-containers
spec:
  containers:
    - name: container-1
      image: busybox:1.36
      command: ["sh", "-c", "sleep infinity"]

    - name: container-2
      image: busybox:1.36
      command: ["sh", "-c", "sleep infinity"]

    - name: container-3
      image: busybox:1.36
      command: ["sh", "-c", "sleep infinity"]

Processes

First, let’s check the processes inside each container.

Container 1

k exec -it three-containers -c container-1 -- sh

/ # ps
PID   USER     TIME  COMMAND
   1 root      0:00 sh -c sleep infinity
  28 root      0:00 sh
  34 root      0:00 ps

Container 2

k exec -it three-containers -c container-2 -- sh

/ # ps
PID   USER     TIME  COMMAND
    1 root      0:00 sh -c sleep infinity
   11 root      0:00 sh
   17 root      0:00 ps

Container 3

k exec -it three-containers -c container-3 -- sh

/ # ps
PID   USER     TIME  COMMAND
    1 root      0:00 sh -c sleep infinity
   11 root      0:00 sh
   17 root      0:00 ps

Each container can only see its own processes.

They do not share processes automatically, and the main process inside each container is PID 1.

Filesystem

Next, let’s check the root filesystem mount information.

Container 2

kubectl exec three-containers -c container-2 -- \
  sh -c 'grep " / / " /proc/self/mountinfo'
2783 2360 0:867 / / rw,relatime - overlay overlay rw,lowerdir=/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/41/fs,upperdir=/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/5717/fs,workdir=/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/5717/work,uuid=on

Container 3

kubectl exec three-containers -c container-3 -- \
  sh -c 'grep " / / " /proc/self/mountinfo'
2838 2404 0:870 / / rw,relatime - overlay overlay rw,lowerdir=/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/41/fs,upperdir=/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/5718/fs,workdir=/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/5718/work,uuid=on

The important part here is the upperdir.

Container 2 uses:

snapshots/5717/fs

Container 3 uses:

snapshots/5718/fs

They are using different writable layers with different snapshot IDs: 5717 and 5718.

This shows that their writable container filesystems are separate, so changes made in one container’s writable layer are not directly visible in the other container.

Network

Now let’s check the network namespace.

Container 2

kubectl exec three-containers -c container-2 -- \
  readlink /proc/1/ns/net
net:[4026538057]

Container 3

kubectl exec three-containers -c container-3 -- \
  readlink /proc/1/ns/net
net:[4026538057]

Both containers have the same network namespace ID:

net:[4026538057]

This proves that the containers are sharing the same network namespace.

Conclusion

From these experiments, we can see that containers in the same Pod behave differently depending on the resource:

  • Processes are isolated by default.
  • Each container has its own writable filesystem layer.
  • Containers in the same Pod share the same network namespace.

So, containers in the same Pod are isolated from each other in terms of processes and writable filesystems, while sharing the same network.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *