Hi everyone,
I am planning a significant upgrade path for our cluster, moving from v1.30 to v1.35. Our environment is currently running on RHEL 8.x with the default 4.18 kernel.
I am aware that v1.35 officially removes support for cgroup v1 (the kubelet now fails to start by default if v1 is detected). While I plan to manually enable cgroup v2 on these RHEL 8 nodes (via systemd.unified_cgroup_hierarchy=1), I have specific concerns regarding the jump across 5 minor versions on this specific OS/Kernel:
-
Kernel 4.18 vs. v1.35 Features: Since v1.35 introduces advanced resource management (like GA In-Place Pod Resizing) and encourages the nftables backend for kube-proxy, does the RHEL 8 (4.18) kernel lack the necessary backports for these to run reliably?
-
Flannel CNI & Networking: We are currently using Flannel. Are there known regressions when running Flannel on a v1.35 control plane while the underlying RHEL 8 nodes are forced into cgroup v2? Specifically, are there any CNI plugin version requirements we should hit before starting the upgrade?
-
Upgrade Path Strategy: Given the jump from 1.30 to 1.35, is it better to perform a “jump” upgrade (re-imaging nodes to RHEL 9) or is the manual cgroup v2 transition on RHEL 8 considered a stable path for the 1.35 lifecycle?
-
Containerd 2.0: We are moving to containerd 2.0 as part of this. Are there any known conflicts between containerd 2.0 and the older systemd version found in RHEL 8 when using cgroup v2?
Current Setup:
Source Version: v1.30
Target Version: v1.35
OS: RHEL 8.2 (Kernel 4.18)
CNI: Flannel
Runtime: containerd 2.0
I’d appreciate any insights from anyone who has managed this specific OS/Kernel combination for the v1.35 release.