Enhancement: Track Potential Change of `kubelet_fail_cgroup_v1` to True

[yankay]

What would you like to be added

A process or mechanism to monitor and evaluate if kubelet_fail_cgroup_v1 should be set to true in the future.

Why is this needed

Currently, kubelet_fail_cgroup_v1 is set to false, but there may be scenarios or best practices in the future where the value should become true. Having a clear record and decision-making process ensures the change will be tracked, assessed for impact, and not overlooked by the team.

[chadswen]

I left some thoughts in this comment.

Agreed, the decision to default failCgroupV1: true was very much intentional as part of the deprecation process. This default raises awareness of cgroup v1's upcoming removal and lack of test support.

Kubespray should back the upstream decision by using the same defaults. We should instruct users to only override the default if they are already aware of the deprecation and have plans to mitigate before cgroupsv1 support is fully removed.

Overriding for CI tests on OSes that we still support via failCgroupV1: false makes sense, though we will need to plan to drop support for those eventually.

If needed, we could also add a roles/kubernetes/preinstall/tasks/0040-verify-settings.yml precheck that fails early if incompatible configuration is detected to prevent kubelet start failures mid-upgrade.

My proposal:

• A precheck that exits fatally with an informative error message when kubelet_fail_cgroup_v1: true is detected on systems that only support cgroupsv1 is probably sufficient to minimize the amount of damage this could cause.
• Documentation updates
  • The mitigation is fairly well summarized in the KEP if we want to reference that in our docs.

[VannTen]

We decided on keeping usptream defaults (aka, failing on cgroup v1 by default).

A precheck that exits fatally with an informative error message when kubelet_fail_cgroup_v1: true is detected on systems that only support cgroupsv1 is probably sufficient to minimize the amount of damage this could cause.

I think kubeadm preflight check does that with SystemVerification ?

I suggest we close this.
We'll also likely follow upstream on the removal of support for cgroup v1, which should occur on v1.39 I think ?
https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/5573-remove-cgroup-v1/README.md#removal-of-cgroup-v1

(removal after all supported K8s version have the deprecation warning)