You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, libcontainer has 4 different cgroup managers:
cgroup v1 cgroupfs-based (aka fs)
cgroup v2 cgroupfs-based (aka fs2)
cgroup v1 systemd-based (aka systemd v1)
cgroup v2 systemd-based (aka systemd v2)
In addition, 3 of the above also implement optional "rootless" functionality,
which can be enabled during manager's instantiation.
Because of the above, there is no easy way to "get a cgroup manager",
and the code that instantiates one is usually complicated. For example,
these almost 100 lines of code:
// Cgroupfs is an options func to configure a LinuxFactory to return containers
// that use the native cgroups filesystem implementation to create and manage
// cgroups.
funcCgroupfs(l*LinuxFactory) error {
returncgroupfs(l, false)
}
// RootlessCgroupfs is an options func to configure a LinuxFactory to return
// containers that use the native cgroups filesystem implementation to create
// and manage cgroups. The difference between RootlessCgroupfs and Cgroupfs is
// that RootlessCgroupfs can transparently handle permission errors that occur
// during rootless container (including euid=0 in userns) setup (while still allowing cgroup usage if
// they've been set up properly).
funcRootlessCgroupfs(l*LinuxFactory) error {
returncgroupfs(l, true)
}
Also, every user of libcontainer/cgroups has to reimplement something like the above. This includes kubernetes, cadvisor, and our tests.
I propose to solve this by
Moving rootless boolean property from the cgroup manager to cgroup config.
Adding Systemd boolean property to cgroup config.
Introducing a new package, libcontainer/cgroups/manager, with the following functions:
// New returns the instance of a cgroup manager, which is chosen// based on the local environment (whether cgroup v1 or v2 is used)// and the config (whether config.Systemd is set or not).funcNew(config*configs.Cgroup) (cgroups.Manager, error) {
returnNewWithPaths(config, nil)
}
// NewWithPaths is similar to New, and can be used in case cgroup paths// are already well known, which can save some resources.//// For cgroup v1, the keys are controller/subsystem name, and the values// are absolute filesystem paths to the appropriate cgroups.//// For cgroup v2, the only key allowed is "" (empty string), and the value// is the unified cgroup path.funcNewWithPaths(config*configs.Cgroup, pathsmap[string]string) (cgroups.Manager, error)
With this in place, the above code (first example) is replaced with something like
cm, err:=manager.New(config.Cgroups)
iferr!=nil {
returnerr
}
In a similar way, external users (kubernetes, cadvisor) can simplify cgroup manager instantiation.
The text was updated successfully, but these errors were encountered:
Currently, libcontainer has 4 different cgroup managers:
In addition, 3 of the above also implement optional "rootless" functionality,
which can be enabled during manager's instantiation.
Because of the above, there is no easy way to "get a cgroup manager",
and the code that instantiates one is usually complicated. For example,
these almost 100 lines of code:
runc/libcontainer/factory_linux.go
Lines 58 to 150 in f67f1ef
Also, every user of libcontainer/cgroups has to reimplement something like the above. This includes kubernetes, cadvisor, and our tests.
I propose to solve this by
rootless
boolean property from the cgroup manager to cgroup config.Systemd
boolean property to cgroup config.libcontainer/cgroups/manager
, with the following functions:With this in place, the above code (first example) is replaced with something like
In a similar way, external users (kubernetes, cadvisor) can simplify cgroup manager instantiation.
The text was updated successfully, but these errors were encountered: