Re: name=systemd cgroup mounts/hierarchy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Do, 12.11.20 20:05, Andrei Enshin (b1os@xxxxx) 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
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel




[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux