diff --git a/content/en/docs/setup/cri.md b/content/en/docs/setup/cri.md
index 4717eddc144e7..a60adc5aa3d3a 100644
--- a/content/en/docs/setup/cri.md
+++ b/content/en/docs/setup/cri.md
@@ -26,6 +26,24 @@ Please refer to this link for more information about this issue
 [cve-2019-5736 : runc vulnerability ] (https://access.redhat.com/security/cve/cve-2019-5736)
 {{< /caution >}}
 
+## Cgroup drivers
+
+When systemd is chosen as the init system for a Linux distribution, the init process generates
+and consumes a root cgroup and acts as a cgroup manager. Systemd has a tight integration with
+cgroups and will allocate cgroups per process. It's possible to configure your container
+runtime and the kubelet to use `cgroupfs`. This means that there will then be two different
+cgroup managers.
+
+Cgroups are used to constrain resources that are allocated to processes. 
+A single cgroup manager will simplify the view of what resources are being allocated
+and will by default have a more consistent view of the available and in-use resources. When we have
+two managers we end up with two views of those resources. We have seen cases in the field
+where nodes that are configured to use `cgroupfs` for the kubelet and Docker, and `systemd`
+for the rest of the processes running on the node becomes unstable under resource pressure.
+
+Changing the settings such that your container runtime and kubelet use `systemd` as the cgroup driver
+stabilized the system. Please note the `native.cgroupdriver=systemd` option in the Docker setup below.
+
 ## Docker
 
 On each of your machines, install Docker.
@@ -59,7 +77,7 @@ apt-get update && apt-get install docker-ce=18.06.2~ce~3-0~ubuntu
 # Setup daemon.
 cat > /etc/docker/daemon.json <<EOF
 {
-  "exec-opts": ["native.cgroupdriver=cgroupfs"],
+  "exec-opts": ["native.cgroupdriver=systemd"],
   "log-driver": "json-file",
   "log-opts": {
     "max-size": "100m"