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

group of whales is called a pod. Consider a pod of two humpback whales. One whale is grey in color and other is blue.

What is the color of the pod? The question doesn't make much sense as color is the property of each individual whale.

What is the species of the pod? Well you can say it is a humbpack pod as all the whales in the pod are humpback whales but again species has nothing to do with the pod. It is the individual whale that belongs to that species.

Similarly group of containers is a pod in Kubernetes. Properties like cgroups and namespaces are applicable for containers. Sometimes it is convenient to talk about some properties at pod level like network namespace or IPC namespace because all the containers in the pod usually share the same network and IPC namespaces. But inherently they are container properties.