Namespaces control what the processes inside of the containers can see, cgroup controls how much resources they can use. Namespace is about isolation, cgroup is about "budget" control.
Follow the same methodology as we did when walking through the namespaces usage in container, we'll create/run a container first, then run a new a process in the container and see how the cgroup in the host system changes; and then we see how to config the cgroup, firstly manually manipulating the host cgroup files and then using the runc config files and docker cli command.
Take a snapshot of the cgroups before creating a container using the following command.
lscgroupis command line tool that lists all the cgroup currently in the system, simply by walk
Start a container and record the cgroups after that,
Check the cgroup difference:
As we can see, for each cgroup type, a new cgroup
xyxy12is created, underneath its parent's cgroup, which is the cgroups of the
bashin which we issued the
Who is under control?
cgroup control processes, it mandates how much memory/cpu/etc. a process or a group of processes can use. Adding a process into cgroup, is simpling add the process pid to the groups's
First, find out the pid of the container('s init process).
Check who are in the variouse cgroups (using memory and cpu cgroup as examples):
Ok. It is clear that the container's init process is put into the newly created cgroups dedicated for that container. And, to make the description complete, to find out the cgroups a process is in, just cat
We are pretty happy with what we have found, but still, want to see how the new processes started in the container related to the container.
start a new process inside of the container xyxy12.
Check if any new cgroups are created
Nope. No new cgroups are created when exec a new process inside of an already running container.
Then, how the newly created process is related to the cgroup created by the container? Find the process of the new process first. It is 32123, and note that it is in the runtime namespace.
Check the memory and cpu cgrups for the container. Fwiw, the pattern is "/sys/fs/cgroup/
All right, it means the new process will be added to the cgroups created in the first container run.
To summary, when a container is created, a new cgroup group will be created for each type of the resources and all the processes running in the container will be put into that group (for each type). Hence the resources the processes in the container can be controlled through those cgroups.
We know now when the cgroups are created and what and how processes are put into each groups. Finally, it is time to see actually how to use the cgroup to put some constraints on the processes. Memory constraint/cgroup is the easiest to understand, and we'll use that as an example.
However, if you check the memory cgroup configuration for the xyxy12, it is actually isn't set at all. I don't know where 9223372036854771712 is come from but that's for sure not a useful limitation.
To config a limit is as easy as write a sys fs file.
With this setting in place, any processes in the container won't be able to use more memory than 100M, once it exceeds, it will be killed, or paused, depending on the memory.oom_control setting.
Actually, you are not supposed to config the cgroup that way (but it is what happens under the hood).
For runc, it can be easily set in the
config.json. Adding following config snippet in linux.resources section, you are limit all the processes lunching in a container with max 100M memory.
Under the the hood, the runc will write the file for you. And it can be revealed by changing the value from 100000000 to 100000, which will cause an error:
If you use docker, the memory limit can be specified in the docker run command, with the
--memoryoption, which will be converted to a config file passing to runc, and which will write corresponding sys fs file.
In this blog we'll walk through how Linux cgroup is used in container.
- a new cgroup will be created for a new container
- exec a new process in a running container will join the created new cgroups
- config the cgroup properly so that the processes in the container are controlled.