Use systemd cgroup manager when kubelet/containerd are managed by systemd unit

[fabriziopandini]

User Story

As a user, I would like to use systemd cgroup driver when kubelet/containerd are managed by systemd unit.

Detailed Description

Image builder is using systemd unit to run both kubelet and containerd; systemd allocates a cgroup per systemd unit, while instead both kubelet and containerd uses cgroupfs as a default cgroup driver.

As a result, there will be two different cgroup managers on each machine and this leads you to have two views of machines's resources; In the field, people have reported cases where such systems become unstable under resource pressure (see here for more context)

This is not ideal; instead, we should make sure everything is configured to use the systemd cgroup driver only.
In order to make this happen a coordinated, multi project effort is required:

• We should make sure the image builder configures containerd for using the systemd cgroup driver. This effort is tracked in containerd should be using systemd cgroup hierarchy image-builder#471; the assumption here is that this will be the default for images with Kubernetes version >= v1.21
• We should make sure that kubeadm defaults the Kubelet Configuration for using systemd cgroup driver. This effort is tracked in default the "cgroupDriver" setting of the kubelet to "systemd" kubernetes/kubeadm#2376; also here, the assumption is that this will be the default for cluster initialized with Kubernetes version >= v1.21
• We should make sure that the KubeadmControlPlane would update the KubeletConfiguration when executing upgrades from v1.20 to v1.21. this effort should be tracked in this repository and backported to the v0.3 branch
• TBD how to handle this change in CAPD

Anything else you would like to add:

We should account for configurations not using containerd, not using systemd and for configuration not using kubeadm as a bootstrap/controlplane provider.

Given that both image builder and kubeadm allow overriding the default and that the KubeadmControlPlane is optional I don't see blockers for these scenarios, but if everyone has more context on these use cases, please comment.

This was discussed during CAPI office hours on the 20th of January.

/kind feature

[fabriziopandini]

/milestone v0.4.0
/priority important-soon

/assign

[neolit123]

i've sent the PR for moving to systemd in kubeadm 1.21:
kubernetes/kubernetes#99471

[fabriziopandini]

/lifecycle active