Hi.
On Wed, Nov 18, 2020 at 09:46:03PM +0300, Andrei Enshin <b1os@xxxxx> wrote:
> Just out of curiosity, how systemd in particular may be disrupted with
> such record in root of it’s cgroups hierarchy as /kubpods/bla/bla
> during service (de)activation?
> Or how it may disrupt the kubelet or workload running by it?
If processes from kubeletet.service are migrated elsewhere, systemd may
lose ability to associate it with the service (which may or may not be
correct, I didn't check this particular case).
In the opposite direction, if container runtime builds up a hierarchy
for a controller, systemd isn't aware of it and it would clean the
hierarchy according to its configuration (which can, for instance, be no
controllers at all) and happens during unit (de)activation. The
containers can get away with it when there are no unit changes at the
moment but that's not what you want. Furthermore, since cgroup
operations for a unit usually involve family [1], the interference may
happen even when apparently unrelated unit changes. (This applies to the
most common "hybrid" cgroup layout.)
> Seems I missed some technical details how exact it will interfere.
There's the defined interface (delegation or DBus API) and both parties
(systemd, container runtimes) have freedom to implement cgroups as they
wish within these limits.
If they overlap though, you get an undefined behavior in principle.
That's the reason why to stick to this convention.
Michal
[1] This is rather an implementation detail
https://github.com/systemd/systemd/blob/f56a9cbf9c20cd798258d3db302d51bf21458b38/src/core/cgroup.c#L2326
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
