This chapter covers:
- Introducing cgroups and systemd concepts
- The various dimensions of hierarchy used to create new cgroups
- Some of the paradigms that face the evolution of the container runtime interface for Kubernetes.
- How systemd and cgroups can be inspected in the real world, and how they intersect in day-to-day operations
- How to use Kubernetes to schedule high-priority processes
Although Kubernetes itself has scheduling capabilities, these are no substitute for the most fundamental scheduler in the Linux operating system, Systemd. Systemd initializes the parent for all processes in your operating system (PID 1) and uses cgroups to restrict the amount of resources (CPU, RAM, etc.) that these programs, and their children, use.
The most infamous of all of these children is the pause container.
This whole chapter is about resources and isolation. The term Resource fencing refers to isolating the resources allocated to a process, which might be CPU, disk, memory. This isolating happens automatically in the cloud when you make a VM - the VM has virtual access to a limited amount of resources on a hypervisor. But what about for local processes on a single OS? At this level, you isolate one program from another with cgroups.
Let’s look at what you can do without any resource fencing. For example, if you run: