Change:
This section: I would add information like here: Note: In v1.22, if the user is not setting the cgroupDriver field under KubeletConfiguration, kubeadm will default it to systemd.
this section: already links to: PRs welcome with proposed improvements. /help /sig cluster-lifecycle
If someone wants to help here, I'm not sure what steps they should follow to assist. Because of that: /remove-help
/language en
I think the suggestion is to add something about to container-runtimes pages but I don't think that fits well on that page because it only covers the container runtime side. What could be though is that there's a note/reminder to ensure they are always the same. I can work on that if we agree what's what we want here.
hmm, looks like this is already covered too.
some additional feedback in
/triage accepted
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]:
/assign

Discussion:
check the documentation for that version. {{< /note >}} <!-- body --> ## Install and configure prerequisites <del> The following steps apply common settings for Kubernetes nodes on Linux. </del> <ins> The following steps apply common settings for Kubernetes nodes on Linux. </ins> You can skip a particular setting if you're certain you don't need it. <del> For more information, see [Network Plugin Requirements](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#network-plugin-requirements) or the documentation for your specific container runtime. </del> <ins> For more information, see [Network Plugin Requirements](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#network-plugin-requirements) or the documentation for your specific container runtime. </ins> ### Forwarding IPv4 and letting iptables see bridged traffic

sudo sysctl --system ``` <del> Verify that the `br_netfilter`, `overlay` modules are loaded by running below instructions: </del> <ins> Verify that the `br_netfilter`, `overlay` modules are loaded by running the following commands: </ins> ```bash lsmod | grep br_netfilter lsmod | grep overlay ``` <del> Verify that the `net.bridge.bridge-nf-call-iptables`, `net.bridge.bridge-nf-call-ip6tables`, `net.ipv4.ip_forward` system variables are set to 1 in your `sysctl` config by running below instruction: </del> <ins> Verify that the `net.bridge.bridge-nf-call-iptables`, `net.bridge.bridge-nf-call-ip6tables`, and `net.ipv4.ip_forward` system variables are set to `1` in your `sysctl` config by running the following command: </ins> ```bash sysctl net.bridge.bridge-nf-call-iptables net.bridge.bridge-nf-call-ip6tables net.ipv4.ip_forward ``` <del> ## Cgroup drivers </del> <ins> ## cgroup drivers </ins> On Linux, {{< glossary_tooltip text="control groups" term_id="cgroup" >}} are used to constrain resources that are allocated to processes. <del> Both {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} and the </del> <ins> Both the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} and the </ins> underlying container runtime need to interface with control groups to enforce <del> [resource management for pods and containers](/docs/concepts/configuration/manage-resources-containers/) and set resources such as cpu/memory requests and limits. To interface with control </del> <ins> [resource management for pods and containers](/docs/concepts/configuration/manage-resources-containers/) and set resources such as cpu/memory requests and limits. To interface with control </ins> groups, the kubelet and the container runtime need to use a *cgroup driver*. <del> It's critical that the kubelet and the container runtime uses the same cgroup </del> <ins> It's critical that the kubelet and the container runtime use the same cgroup </ins> driver and are configured the same. There are two cgroup drivers available:

### cgroupfs driver {#cgroupfs-cgroup-driver} <del> The `cgroupfs` driver is the default cgroup driver in the kubelet. When the `cgroupfs` driver is used, the kubelet and the container runtime directly interface with the cgroup filesystem to configure cgroups. </del> <ins> The `cgroupfs` driver is the [default cgroup driver in the kubelet](docs/reference/config-api/kubelet-config.v1beta1). When the `cgroupfs` driver is used, the kubelet and the container runtime directly interface with the cgroup filesystem to configure cgroups. </ins> The `cgroupfs` driver is **not** recommended when [systemd](https://www.freedesktop.org/wiki/Software/systemd/) is the init system because systemd expects a single cgroup manager on <del> the system. Additionally, if you use [cgroup v2](/docs/concepts/architecture/cgroups) , use the `systemd` cgroup driver instead of `cgroupfs`. </del> <ins> the system. Additionally, if you use [cgroup v2](/docs/concepts/architecture/cgroups), use the `systemd` cgroup driver instead of `cgroupfs`. </ins> ### systemd cgroup driver {#systemd-cgroup-driver}

cgroupDriver: systemd ``` <ins> {{< note >}} Starting with v1.22 and later, when creating a cluster with kubeadm, if the user does not set the `cgroupDriver` field under `KubeletConfiguration`, kubeadm defaults it to `systemd`. {{< /note >}} </ins> If you configure `systemd` as the cgroup driver for the kubelet, you must also configure `systemd` as the cgroup driver for the container runtime. Refer to the documentation for your container runtime for instructions. For example:

This section outlines the necessary steps to use containerd as CRI runtime. <del> To install containerd on your system, follow the instructions on [getting started with containerd](https://github.com/containerd/containerd/blob/main/docs/getting-started.md).Return to this step once you've created a valid `config.toml` configuration file. </del> <ins> To install containerd on your system, follow the instructions on [getting started with containerd](https://github.com/containerd/containerd/blob/main/docs/getting-started.md). Return to this step once you've created a valid `config.toml` configuration file. </ins> {{< tabs name="Finding your config.toml file" >}} {{% tab name="Linux" %}}