Change:
driver of the kubelet. {{< note >}} <del> In v1.22, if the user is not setting the `cgroupDriver` field under `KubeletConfiguration`, `kubeadm` will default it to `systemd`. </del> <ins> In v1.22 and later, if the user does not set the `cgroupDriver` field under `KubeletConfiguration`, kubeadm defaults it to `systemd`. </ins> {{< /note >}} A minimal example of configuring the field explicitly:

Discussion:
says the default value for is . says: The latter does not say, that prior to 1.23 (thus 1.22, 1.21, 1.20) the default was and was later changed to . It says, that in the nearly end-of-life 1.22 the default is . Later contains: In the above text, it is nowhere stated, that there is a plan to switch the default value of KubeletConfiguration.cgroupDriver from cgroupfs to systemd. The last citation suggests, that will perform implicit switch from to . This is strengthened by the fact about 1.22, where the implicit (default) value seems to be . All in all, the above information stipulates, that in 1.22 the default value was , not it is and in the future will use as implicit (default) value again . In the lack of discussion in the documentation why the defauls change back and forth, this does not make sense,
the kubelet default is cgroupfs and it's not clear if the kubelet graduates cgroupv2 support to GA the value will change. afaik, cgroupfs does not support v2. in any case this can be a disruptive change. kubeadm changed its default to systemd because the kubelet in kubeadm setups is managed by systemd. the reason is explained here long term, the cgroup driver detail should not be exposed to users, but that is blocked on some cri work. /kind support
Ah, so the default cgroup driver for kubelet is cgroupfs, while for kubeadm the default is systemd. This shall be spelled explicitly, as it is counter-intuitive. My understanding so far is, that the systemd-driver supports kernel’s cgroup v2, while kubernetes’ cgroup-driver does not support kernel’s cgroup v2. This shall also be spelled explicitly, as it is confusing.
It sounds like the thing to call out is that, in the kubeadm docs, we should explicitly say that the setting that kubeadm applies by default is an override to the built-in kubelet default. Does that sound right?
Yes. Ideally kubeadm and kubelet shall explicitly state, that their default is distinct from the default of the other tool.

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale /help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /remove-lifecycle stale /help </details
/triage accepted
/assign