The Container World | Part 3 Control Groups

In part 3 of my Linux container series, I want to briefly talk about an important aspect of the LXC technology, cgroups. In this post I will explain the cgroup technology as it pertains to LXC and systemd. I will not actually implement cgroups in the tutorial but will show an example of how we will set it up when we do advanced container configuration. Let's get started.

Control Groups (cgroups)

image: access.redhat.com

As mentioned in my first post, control groups (cgroups) play an important role in the container game. Although implementing cgroups into container configs is not mandatory, I would highly recommend implementing the use especially if you are planning to deploy several containers. This will help keep your system stable when you start flooding yourself with containers. Cgroups are a feature of the Linux kernel that allows administrators to allocate and/or restrict resources to containers or processes such as CPU, memory, network bandwidth, and many more. The main purpose for cgroups is to be able to have more complete control over managing and monitoring the host’s system resources and enabling admins to divide up resources among applications and users thus allowing the system to operate more efficiently. Remember that containers are lightweight but we still want to get as much out of our system as we can.

Before the use of systemd style kernel, custom cgroups hierarchies were built using the libcgroup package with the cgconfig command. As systemd becomes the adopted standard Linux kernel, libcgroup is no longer applicable (most of the time although there are certain instances where it can be used). With systemd, cgroups are now managed and created using systemctl. Systemctl gives us the ability to set or modify parameters for a unit or application during runtime from the command line as well as allowing us to modify the unit files in /usr/lib/systemd/system/ and set cgroup parameters there which we wont get into in the post but is good to know.

Systemd by default creates default hierarchical controllers in the /sys/fs/cgroups directory from the automatically created hierarchy of slices, scopes and services. Here is a list of available controllers of interest for containers:

   blkio - Limits I/O access to block devices.
   cpu - Uses a scheduler for tasks.
   cpuacct - Reports on cpu resources used by tasks.
   cpuset - Assigns individual cpus for multicore systems.
   devices - Allows or denies access to devices.
   freezer - Freezes or resumes tasks.
   memory - Limits memory use and generates reports.


For LXC, we will implement these controllers and restrictions within the each container's configuration file. LXC integrates directly with systemd cgroups and is called from the container config file located in /var/lib/lxc/container/config. In order to specify a control group value you will add a line with with the following syntax: lxc.cgroup.[subsystem name]. 

Let's go ahead and take a quick look at an example container config file with cgroup controllers implemented just to get an idea. This is from a default fedora container I created several months ago. 

   [root@centos7-lxchost1]# grep -i cgroup /var/lib/lxc/fedoraContainer1/config 
   #cgroups
   lxc.cgroup.devices.deny = a
   lxc.cgroup.devices.allow = c 1:3 rwm
    lxc.cgroup.devices.allow = c 1:5 rwm
   lxc.cgroup.devices.allow = c 5:1 rwm
   lxc.cgroup.devices.allow = c 5:0 rwm
   lxc.cgroup.devices.allow = c 4:0 rwm
   lxc.cgroup.devices.allow = c 4:1 rwm
   lxc.cgroup.devices.allow = c 1:9 rwm
   lxc.cgroup.devices.allow = c 1:8 rwm
   lxc.cgroup.devices.allow = c 136:* rwm
   lxc.cgroup.devices.allow = c 5:2 rwm
   lxc.cgroup.devices.allow = c 254:0 rm


The example above should give a good overview of how to implement cgroup restrictions into Linux containers. Check out the man page for lxc.conf to get more examples. Check out the next post to start creating our first containers.


Blog Series on Linux Containers:
Previous Post: Host Network
Next Post: First Container