add a blog about KubeletCgroupDriverFromCRI feature

Signed-off-by: Peter Hunt <pehunt@redhat.com>

content/en/blog/_posts/2024-08-21-cgroup-driver-from-cri.md

@@ -0,0 +1,41 @@
+---
+layout: blog
+title: "Configuring Kubernetes just got easier: cgroup driver from CRI"
+date: 2024-07-01
+slug: cgroup driver from CRI to betra
+author: >
+  Peter Hunt (Red Hat)
+---
+
+Historically, a pain point for users running new Kubernetes clusters has been
+the cgroup driver. On Linux systems, there are two different cgroup drivers:
+`cgroupfs` and `systemd`. In the past, both the Kubelet and CRI implementation
+(like CRI-O or containerd) needed to be configured to use the same cgroup
+driver, or else the Kubelet would exit with an error. This was a source of
+headaches for many cluster admins. However, there is light at the end of the
+tunnel!
+
+## `KubeletCgroupDriverFromCRI` Feature Gate
+
+In v1.28.0, the SIG-Node community introduced the feature gate
+`KubeletCgroupDriverFromCRI`, which instructs the Kubelet to ask the CRI
+implementation which cgroup driver to use. It took a couple of releases for
+support to land in the major two CRI implementations, but as of v1.31.0, this
+feature is now beta!
+
+In addition to setting the feature gate, a cluster admin needs to ensure their
+CRI implementation is new enough:
+
+- containerd: Support has been added in v2.0.0
+- CRI-O: Support has been added in v1.28.0
+
+Then, they should ensure their CRI implementation is configured to the
+`cgroup_driver` they would like to use.
+
+## Future Work
+
+Eventually, support for the Kubelet's `cgroupDriver` configuration field will be
+dropped, and the Kubelet will fail to start if the CRI implementation isn't new
+enough to have support for this feature. For now, the Kubelet's `cgroupDriver`
+field is used as a fallback in case the CRI implementation is not new enough,
+and this behavior will also be dropped.