[systemd-devel] name=systemd cgroup mounts/hierarchy

[Andrei Enshin]

Lennart,

> the systemd cgroupfs hierarchy is private property of systemd, and container managers are supposed to follow this logic if they want to interfere with this:  https://systemd.io/CGROUP_DELEGATION/

I see. Thank you for the link. I’ve also read the  https://systemd.io/CONTAINER_INTERFACE/

Seems having the follwing records in the root of named systemd hieararchy is what systemd doesn’t expect:
# ls -ld /sys/fs/cgroup/systemd/docker/
drwxr-xr-x. 2 root root 0 Nov 10 09:58 /sys/fs/cgroup/systemd/docker/

# ls -ld /sys/fs/cgroup/systemd/kubepods/
drwxr-xr-x. 4 root root 0 Jul 16 08:06 /sys/fs/cgroup/systemd/kubepods/
  It is hard to believe that docker/k8s and systemd have not reached agreement.
I’ve asked k8s folks. Maybe there are some reasons for that.
https://groups.google.com/g/kubernetes-sig-node/c/Fuf3OUJ6OvI
https://kubernetes.slack.com/archives/C0BP8PW9G/p1605274049105100

Let’s see what might be the reason.
If you have any ideas why k8s/docker create cgroups in the root of systemd named hierarchy, please share.
Maybe it will bring us faster to common ground.

  
>Friday, November 13, 2020 3:50 PM +03:00 from Lennart Poettering <lennart at poettering.net>:
> 
>On Do, 12.11.20 20:05, Andrei Enshin (b1os at bk.ru) wrote:
> 
>>
>> Hello systemd folks,
>>
>> I have a k8s cluster on CoreOS which uses systemd.
>> There are few nodes after k8s update started to have (maybe it was before) a problem with the following mount:
>>
>> mount ID           2826
>> parent ID           26
>> major:minor       0:23
>> root                    /kubepods/burstable/pod7ffde41a-fa85-4b01-8023-69a4e4b50c55/8842def241fac72cb34fdce90297b632f098289270fa92ec04643837f5748c15
>> mount point      
>> /sys/fs/cgroup/systemd/kubepods/burstable/pod7ffde41a-fa85-4b01-8023-69a4e4b50c55/8842def241fac72cb34fdce90297b632f098289270fa92ec04643837f5748c15
>I am not sure what this is, but your software is doing somethign very
>wrong here. the systemd cgroupfs hierarchy is private property of
>systemd, and container managers are supposed to follow this logic if
>they want to interfere with this:
>
>https://systemd.io/CGROUP_DELEGATION/
>
>The mount point above suggests they are doing something at the top of
>the cgroup tree, instead of their delegated subtree. That's simply
>broken and not supported. The kubernetes people really should know
>better, as this is documented in detail.
>
>Please contact the kubernetes folks and ask them to follow the
>documented interfaces.
>
>Lennart
>
>--
>Lennart Poettering, Berlin 
 
 
---
Best Regards,
Andrei Enshin
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20201116/32e84a92/attachment-0001.htm>