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: 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.
> 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/
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/
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@xxxxxxxxxxxxxx>:
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
---
Best Regards,
Andrei Enshin
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
