Does Kubernetes POD have namespace and cgroup associated with it?

Question

Docker Containers have cgroups and namespaces associated with them, whether they are running in a pod or vm or host machine.
Similarly, does a Kubernetes Pod's have namespaces and cgroups associated with them, or it's just the containers within the pod have these(cgroup & namespace) associations. If they do, how can I find this info from the host?

Answer 1

From the documentation we can read:

"A Pod (as in a pod of whales or pea pod) is a group of one or more containers"

This makes us understand that for every pod we have one or more containers and a cgroup associated to it.

The following answer demonstrates that.

---

Posting this answer as Community Wiki as it is a copy/paste from this answer.

Cgroups

Container in a pod share part of cgroup hierarchy but each container get's it's own cgroup. We can try this out and verify ourself.

1. Start a multi container pod.

# cat mc2.yaml
apiVersion: v1
kind: Pod
metadata:
  name: two-containers
spec:
  restartPolicy: Never
  containers:
  - name: container1
    image: ubuntu
    command: [ "/bin/bash", "-c", "--" ]
    args: [ "while true; do sleep 30; done;" ]

  - name: container2
    image: ubuntu
    command: [ "/bin/bash", "-c", "--" ]
    args: [ "while true; do sleep 30; done;" ]

# kubectl apply -f mc2.yaml
pod/two-containers created

2. Find the process cgroups on the host machine

# ps -ax | grep while | grep -v grep
19653 ?        Ss     0:00 /bin/bash -c -- while true; do sleep 30; done;
19768 ?        Ss     0:00 /bin/bash -c -- while true; do sleep 30; done;

# cat /proc/19653/cgroup
12:hugetlb:/kubepods/besteffort/poda9c80282-3f6b-4d5b-84d5-a137a6668011/ed89697807a981b82f6245ac3a13be232c1e13435d52bc3f53060d61babe1997
11:memory:/kubepods/besteffort/poda9c80282-3f6b-4d5b-84d5-a137a6668011/ed89697807a981b82f6245ac3a13be232c1e13435d52bc3f53060d61babe1997
10:perf_event:/kubepods/besteffort/poda9c80282-3f6b-4d5b-84d5-a137a6668011/ed89697807a981b82f6245ac3a13be232c1e13435d52bc3f53060d61babe1997
9:freezer:/kubepods/besteffort/poda9c80282-3f6b-4d5b-84d5-a137a6668011/ed89697807a981b82f6245ac3a13be232c1e13435d52bc3f53060d61babe1997
8:cpuset:/kubepods/besteffort/poda9c80282-3f6b-4d5b-84d5-a137a6668011/ed89697807a981b82f6245ac3a13be232c1e13435d52bc3f53060d61babe1997
7:net_cls,net_prio:/kubepods/besteffort/poda9c80282-3f6b-4d5b-84d5-a137a6668011/ed89697807a981b82f6245ac3a13be232c1e13435d52bc3f53060d61babe1997
6:cpu,cpuacct:/kubepods/besteffort/poda9c80282-3f6b-4d5b-84d5-a137a6668011/ed89697807a981b82f6245ac3a13be232c1e13435d52bc3f53060d61babe1997
5:blkio:/kubepods/besteffort/poda9c80282-3f6b-4d5b-84d5-a137a6668011/ed89697807a981b82f6245ac3a13be232c1e13435d52bc3f53060d61babe1997
4:pids:/kubepods/besteffort/poda9c80282-3f6b-4d5b-84d5-a137a6668011/ed89697807a981b82f6245ac3a13be232c1e13435d52bc3f53060d61babe1997
3:devices:/kubepods/besteffort/poda9c80282-3f6b-4d5b-84d5-a137a6668011/ed89697807a981b82f6245ac3a13be232c1e13435d52bc3f53060d61babe1997
2:rdma:/
1:name=systemd:/kubepods/besteffort/poda9c80282-3f6b-4d5b-84d5-a137a6668011/ed89697807a981b82f6245ac3a13be232c1e13435d52bc3f53060d61babe1997
0::/

# cat /proc/19768/cgroup
12:hugetlb:/kubepods/besteffort/poda9c80282-3f6b-4d5b-84d5-a137a6668011/e10fa18a63cc26de27f3f79f46631cd814efa3ef7c2f5ace4b84cf5abce89765
11:memory:/kubepods/besteffort/poda9c80282-3f6b-4d5b-84d5-a137a6668011/e10fa18a63cc26de27f3f79f46631cd814efa3ef7c2f5ace4b84cf5abce89765
10:perf_event:/kubepods/besteffort/poda9c80282-3f6b-4d5b-84d5-a137a6668011/e10fa18a63cc26de27f3f79f46631cd814efa3ef7c2f5ace4b84cf5abce89765
9:freezer:/kubepods/besteffort/poda9c80282-3f6b-4d5b-84d5-a137a6668011/e10fa18a63cc26de27f3f79f46631cd814efa3ef7c2f5ace4b84cf5abce89765
8:cpuset:/kubepods/besteffort/poda9c80282-3f6b-4d5b-84d5-a137a6668011/e10fa18a63cc26de27f3f79f46631cd814efa3ef7c2f5ace4b84cf5abce89765
7:net_cls,net_prio:/kubepods/besteffort/poda9c80282-3f6b-4d5b-84d5-a137a6668011/e10fa18a63cc26de27f3f79f46631cd814efa3ef7c2f5ace4b84cf5abce89765
6:cpu,cpuacct:/kubepods/besteffort/poda9c80282-3f6b-4d5b-84d5-a137a6668011/e10fa18a63cc26de27f3f79f46631cd814efa3ef7c2f5ace4b84cf5abce89765
5:blkio:/kubepods/besteffort/poda9c80282-3f6b-4d5b-84d5-a137a6668011/e10fa18a63cc26de27f3f79f46631cd814efa3ef7c2f5ace4b84cf5abce89765
4:pids:/kubepods/besteffort/poda9c80282-3f6b-4d5b-84d5-a137a6668011/e10fa18a63cc26de27f3f79f46631cd814efa3ef7c2f5ace4b84cf5abce89765
3:devices:/kubepods/besteffort/poda9c80282-3f6b-4d5b-84d5-a137a6668011/e10fa18a63cc26de27f3f79f46631cd814efa3ef7c2f5ace4b84cf5abce89765
2:rdma:/
1:name=systemd:/kubepods/besteffort/poda9c80282-3f6b-4d5b-84d5-a137a6668011/e10fa18a63cc26de27f3f79f46631cd814efa3ef7c2f5ace4b84cf5abce89765
0::/

As you can see the containers in the pods share the cgroup hierarchy until /kubepods/besteffort/poda9c80282-3f6b-4d5b-84d5-a137a6668011 and then they get their own cgroup. (These containers are under besteffort cgroup because we have not specified the resource requests)

You can also find the cgroups of the container by logging into the container and viewing /proc/self/cgroup file. (This may not work in recent versions of kubernetes if cgroup namespace is enabled)

# kubectl exec -it two-containers -c container2 bash
# root@two-containers:# cat /proc/self/cgroup
12:hugetlb:/kubepods/besteffort/poda9c80282-3f6b-4d5b-84d5-a137a6668011/ed89697807a981b82f6245ac3a13be232c1e13435d52bc3f53060d61babe1997
11:memory:/kubepods/besteffort/poda9c80282-3f6b-4d5b-84d5-a137a6668011/ed89697807a981b82f6245ac3a13be232c1e13435d52bc3f53060d61babe1997
10:perf_event:/kubepods/besteffort/poda9c80282-3f6b-4d5b-84d5-a137a6668011/ed89697807a981b82f6245ac3a13be232c1e13435d52bc3f53060d61babe1997
9:freezer:/kubepods/besteffort/poda9c80282-3f6b-4d5b-84d5-a137a6668011/ed89697807a981b82f6245ac3a13be232c1e13435d52bc3f53060d61babe1997
8:cpuset:/kubepods/besteffort/poda9c80282-3f6b-4d5b-84d5-a137a6668011/ed89697807a981b82f6245ac3a13be232c1e13435d52bc3f53060d61babe1997
7:net_cls,net_prio:/kubepods/besteffort/poda9c80282-3f6b-4d5b-84d5-a137a6668011/ed89697807a981b82f6245ac3a13be232c1e13435d52bc3f53060d61babe1997
6:cpu,cpuacct:/kubepods/besteffort/poda9c80282-3f6b-4d5b-84d5-a137a6668011/ed89697807a981b82f6245ac3a13be232c1e13435d52bc3f53060d61babe1997
5:blkio:/kubepods/besteffort/poda9c80282-3f6b-4d5b-84d5-a137a6668011/ed89697807a981b82f6245ac3a13be232c1e13435d52bc3f53060d61babe1997
4:pids:/kubepods/besteffort/poda9c80282-3f6b-4d5b-84d5-a137a6668011/ed89697807a981b82f6245ac3a13be232c1e13435d52bc3f53060d61babe1997
3:devices:/kubepods/besteffort/poda9c80282-3f6b-4d5b-84d5-a137a6668011/ed89697807a981b82f6245ac3a13be232c1e13435d52bc3f53060d61babe1997
2:rdma:/
1:name=systemd:/kubepods/besteffort/poda9c80282-3f6b-4d5b-84d5-a137a6668011/ed89697807a981b82f6245ac3a13be232c1e13435d52bc3f53060d61babe1997
0::/

---

Namespaces

Containers in pod also share network and IPC namespaces by default.

# cd /proc/19768/ns/
# /proc/19768/ns# ls -lrt
total 0
lrwxrwxrwx 1 root root 0 Jul  4 01:41 uts -> uts:[4026536153]
lrwxrwxrwx 1 root root 0 Jul  4 01:41 user -> user:[4026531837]
lrwxrwxrwx 1 root root 0 Jul  4 01:41 pid_for_children -> pid:[4026536154]
lrwxrwxrwx 1 root root 0 Jul  4 01:41 pid -> pid:[4026536154]
lrwxrwxrwx 1 root root 0 Jul  4 01:41 net -> net:[4026536052]
lrwxrwxrwx 1 root root 0 Jul  4 01:41 mnt -> mnt:[4026536152]
lrwxrwxrwx 1 root root 0 Jul  4 01:41 ipc -> ipc:[4026536049]
lrwxrwxrwx 1 root root 0 Jul  4 01:41 cgroup -> cgroup:[4026531835]

# cd /proc/19653/ns
# /proc/19653/ns# ls -lrt
total 0
lrwxrwxrwx 1 root root 0 Jul  4 01:42 uts -> uts:[4026536150]
lrwxrwxrwx 1 root root 0 Jul  4 01:42 user -> user:[4026531837]
lrwxrwxrwx 1 root root 0 Jul  4 01:42 pid_for_children -> pid:[4026536151]
lrwxrwxrwx 1 root root 0 Jul  4 01:42 pid -> pid:[4026536151]
lrwxrwxrwx 1 root root 0 Jul  4 01:42 net -> net:[4026536052]
lrwxrwxrwx 1 root root 0 Jul  4 01:42 mnt -> mnt:[4026536149]
lrwxrwxrwx 1 root root 0 Jul  4 01:42 ipc -> ipc:[4026536049]
lrwxrwxrwx 1 root root 0 Jul  4 01:42 cgroup -> cgroup:[4026531835]

As you can see the containers share the network and IPC namespaces. You can also make the container share pid namespace using shareProcessNamespace field in the pod spec.

https://kubernetes.io/docs/tasks/configure-pod-container/share-process-namespace

---

cgroup:[4026531835] is same for both the containers. Is this(cgroup namespace) different from the cgroups they (containers) are part of.

cgroups limits the resources(cpu, memory etc) which a process(or group of processes) can use.

namespaces isolate and limit the visibility a process(or a group of processes) has over system resources like network, process trees etc. There are different namespace groups like network, IPC etc. One of such namespace is cgroup namespace. Using cgroup namespace you can limit the visibility of other cgroups from a process(or group of processes)

cgroup namespace virtualises the view of a process's cgroups. Currently if you try cat /proc/self/cgroup from within the container, you would be able to see the full cgroup hierarchy starting from the global cgroup root. This can be avoided using cgroup namespaces and is available from kubernetes v1.19. Docker also supports this from version 20.03. When cgroup namespace is used while creating the container, you would see the cgroup root as / inside the container instead of seeing the global cgroups hierarchy.

https://man7.org/linux/man-pages/man7/cgroup_namespaces.7.html