Resolve the issue where kubeadm initialization prompts cgroups v1 support is in maintenance mode, please migrate to cgroups v2

Overview

When initializing the control plane with kubeadm on Ubuntu 20.04, it prompts cgroups v1 support is in maintenance mode, please migrate to cgroups v2. It doesn't affect usage, but it's annoying to look at!

Solve

According to your mount | grep cgroup Output, your Ubuntu 20.04 system is currently in cgroups v1 and v2 hybrid mode, but The actual default is cgroups v1. The following is a detailed analysis and targeted recommendations:

1. Current cgroups status analysis

mount point	Type	Explanation
/sys/fs/cgroup/unified	cgroup2	v2 Unified Hierarchy(Key subsystem not actually used)
/sys/fs/cgroup/{systemd,cpu,memory,...}	cgroup	v1 subsystem(Resources under actual control)

• Key conclusions:

• system Supports both v1 and v2, but all core subsystems (CPU, memory, devices, etc.) still through cgroups v1 Mount.

• Kubernetes/Docker default to using v1 unless explicitly configured to v2.

2. Impact on Kubernetes

• Current status: kubeadm warning ([WARNING SystemVerification]: cgroups v1) indicates that your cluster is running on cgroups v1, but future versions may no longer support it.

• risk: Long-term use of v1 may cause compatibility issues (especially with newer Kubernetes versions).

3. Two solutions

Choose according to your needs:

Option 1: Keep cgroups v1 (compatible with the existing environment)

• Applicable scenarios: The production environment is running stably, or there are no strict version requirements.

• Operating recommendations: Ignore the warning, but ensure that Kubernetes components use a consistent cgroup driver (recommended systemd):

# Check kubelet configuration
cat /var/lib/kubelet/config.yaml | grep cgroupDriver
# If it's not systemd, restart after making the changes
sudo sed -i 's/cgroupDriver:.*/cgroupDriver: systemd/' /var/lib/kubelet/config.yaml
sudo systemctl restart kubelet

Option 2: Fully switch to cgroups v2 (recommended for new clusters)

• Applicable scenarios: Newly deployed environment or test cluster.

• Operating steps:

Step 1: Enable cgroups v2 and disable v1

sudo nano /etc/default/grub

Modify GRUB_CMDLINE_LINUX OK, add the following parameters:

GRUB_CMDLINE_LINUX="... systemd.unified_cgroup_hierarchy=1 cgroup_no_v1=all"

Update GRUB and reboot:

sudo update-grub
sudo reboot

Step 2: Verify the switching result

mount | grep cgroup

The expected output should only remain cgroup2 Mount point:

cgroup2 on /sys/fs/cgroup type cgroup2 (rw,...)

Step 3: Reconfigure Kubernetes and Docker

• Docker:

echo '{"exec-opts": ["native.cgroupdriver=systemd"]}' | sudo tee /etc/docker/daemon.json
sudo systemctl restart docker

• Kubernetes:

sudo kubeadm reset
sudo rm -rf /etc/kubernetes/ $HOME/.kube
# Explicitly specify the cgroup driver during reinitialization
sudo kubeadm init --cgroup-driver=systemd ...

4. Precautions

• Data compatibility: After switching the cgroups version,Existing containers/Pods may need to be recreated..

• Legacy tool compatibility: Some monitoring tools (such as cadvisor) may need to be upgraded to support cgroups v2.

• Rollback method: Delete from GRUB parameters cgroup_no_v1=all and restart to restore v1.

5. Extended inspection

Confirm the current system's cgroup driver:

docker info | grep -i cgroup  # The driver used by Docker
kubelet --help | grep cgroup-driver  # Drivers supported by Kubelet

Please choose a solution according to your actual needs. If you need more specific operational guidance (such as migrating while retaining existing cluster data), please provide more details about your scenario!