This is getting a little long in the tooth but I created a few videos and did some tests around cgroups back in 2013-2014. Both these help explain the underpinnings of Docker and I guess Kubernetes now too. Turtles all the way up. I'm just mentioning this since these are still some of my most popular videos and still the core tech under the hood.<p>A personal note here too. cgroups were invented at Google in the early 2000's. If you're using search today, gmail, docs, maps, etc. You're using cgroups. It sounds simple but this tech really powered a whole wave of innovation/startups/projects that almost everyone interacts with on a daily basis. Either through touching a Google service or interacting with anyone using Docker or Kubernetes (running on cgroups/namespaces). Pretty impressive.<p>#14 - Introduction to Linux Control Groups (Cgroups)<p><a href="https://sysadmincasts.com/episodes/14-introduction-to-linux-control-groups-cgroups" rel="nofollow">https://sysadmincasts.com/episodes/14-introduction-to-linux-...</a><p>#24 - Introduction to Containers on Linux using LXC<p><a href="https://sysadmincasts.com/episodes/24-introduction-to-containers-on-linux-using-lxc" rel="nofollow">https://sysadmincasts.com/episodes/24-introduction-to-contai...</a>
These things should strive for accuracy and this article is not accurate. The cgroups facility does not control "the number of CPU shares per process." Although you can put such a thing into effect with control groups, it's more accurate to say that a control group limits the resources of a set of tasks. Those tasks may be from one or several processes, and it's also the case that a single process can divide its own tasks into several cgroups.
This is Part I from a series.
Part II: <a href="https://www.redhat.com/sysadmin/cgroups-part-two" rel="nofollow">https://www.redhat.com/sysadmin/cgroups-part-two</a>
Part III: <a href="https://www.redhat.com/sysadmin/cgroups-part-three" rel="nofollow">https://www.redhat.com/sysadmin/cgroups-part-three</a>
Part IV: <a href="https://www.redhat.com/sysadmin/cgroups-part-four" rel="nofollow">https://www.redhat.com/sysadmin/cgroups-part-four</a>
Found an interesting ongoing blogpost series that also tries to explain all the other low level kernel mechanism that make up Docker and other container technologies on Linux. They haven't reach the topic of control groups though.<p><a href="https://www.schutzwerk.com/en/43/posts/linux_container_intro/" rel="nofollow">https://www.schutzwerk.com/en/43/posts/linux_container_intro...</a>
I wrote a blog post on cgroups a couple years ago that's still accurate and goes further into depth and gives workable examples of using them both inside and outside of containers: <a href="https://www.grant.pizza/blog/understanding-cgroups/" rel="nofollow">https://www.grant.pizza/blog/understanding-cgroups/</a>
I like the cgroups approach because it seems to logically build on the established idea of process groups.<p>I also tend to think that processes in cgroups are a sweet spot of lightweight containerization that can do quite a bit.
Ah yes, "cgroups", according to notable no-nonsense kernel hacker Al Viro:<p>"it's not just badly written kernel/cgroup.c - the interfaces on <i>both</i> sides (userland and the rest of kernel) are seriously misdesigned. As far as I'm concerned, configuring it out solves my problem nicely."<p>That was in 2011, so things might have improved. What remains however is that cgroups was added to the kernel, by Googlers, for easier maintenance, but with an implicit understanding that no sane person would actually make use of it to do something important.<p>... enter SystemD.