[systemd-devel] Feedback sought: can we drop cgroupv1 support soon?

[Luca Boccassi]

On Wed, 19 Jul 2023 at 13:45, Neal Gompa <ngompa13 at gmail.com> wrote:
>
> On Thu, Jul 21, 2022 at 6:15 AM Lennart Poettering
> <lennart at poettering.net> wrote:
> >
> > Heya!
> >
> > It's currently a terrible mess having to support both cgroupsv1 and
> > cgroupsv2 in our codebase.
> >
> > cgroupsv2 first entered the kernel in 2014, i.e. *eight* years ago
> > (kernel 3.16). We soon intend to raise the baseline for systemd to
> > kernel 4.3 (because we want to be able to rely on the existance of
> > ambient capabilities), but that also means, that all kernels we intend
> > to support have a well-enough working cgroupv2 implementation.
> >
> > hence, i'd love to drop the cgroupv1 support from our tree entirely,
> > and simplify and modernize our codebase to go cgroupv2-only. Before we
> > do that I'd like to seek feedback on this though, given this is not
> > purely a thing between the kernel and systemd — this does leak into
> > some userspace, that operates on cgroups directly.
> >
> > Specifically, legacy container infra (i.e. docker/moby) for the
> > longest time was cgroupsv1-only. But as I understand it has since been
> > updated, to cgroupsv2 too.
> >
> > Hence my question: is there a strong community of people who insist on
> > using newest systemd while using legacy container infra? Anyone else
> > has a good reason to stick with cgroupsv1 but really wants newest
> > systemd?
> >
> > The time where we'll drop cgroupv1 support *will* come eventually
> > either way, but what's still up for discussion is to determine
> > precisely when. hence, please let us know!
> >
>
> The main concern I have about cgroup v1 removal is that some major
> Kubernetes distributions don't support cgroup v2 yet. Upstream
> Kubernetes only started fully supporting cgroup v2 with Kubernetes
> 1.25, as noted in their documentation:
> https://kubernetes.io/docs/concepts/architecture/cgroups/
>
> OpenShift just added support in 4.13 (but didn't enable it by default
> yet): https://cloud.redhat.com/blog/cgroups-v2-goes-ga-in-openshift-4.13
>
> AKS seems to only support cgroup v2 with Ubuntu 22.04:
> https://learn.microsoft.com/en-us/azure/aks/supported-kubernetes-versions?tabs=azure-cli#aks-components-breaking-changes-by-version
>
> (No mention of Azure Linux? I'm pretty sure CBL-Mariner is cgroup v2 only)
>
> It is unclear whether EKS supports cgroup v2 at all (I suspect not,
> since EKS doesn't yet run on Amazon Linux 2023):
> https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html
>
> It is similarly unclear with GKE:
> https://cloud.google.com/kubernetes-engine/docs/concepts/node-images
>
> (The version of Ubuntu is not mentioned in the documentation, if it's
> not new enough, it's still cgroup v1)
>
> DigitalOcean Kubernetes Service (DOKS) is still cgroup v1:
> https://docs.digitalocean.com/products/kubernetes/details/changelog/
>
> Linode Kubernetes Engine (LKE) is still cgroup v1:
> https://www.linode.com/docs/products/compute/kubernetes/release-notes/
>
> It is possible that systemd's deprecation will push things over the
> edge, but I wanted to make sure people are aware of this.

Are you sure that in all those cases it's really not supported at all,
vs simply not being the default configuration that can be changed with
a toggle?