Re: Feedback sought: can we drop cgroupv1 support soon?

[Neal Gompa <ngompa13@xxxxxxxxx>]

On Wed, Jul 19, 2023 at 8:52 AM Luca Boccassi <luca.boccassi@xxxxxxxxx> wrote:
>
> On Wed, 19 Jul 2023 at 13:45, Neal Gompa <ngompa13@xxxxxxxxx> wrote:
> >
> > On Thu, Jul 21, 2022 at 6:15 AM Lennart Poettering
> > <lennart@xxxxxxxxxxxxxx> 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?

If it's not mentioned, it's probably not supported. And especially
with managed Kubernetes, it's pretty rare to allow such kind of
configuration changes.




--
真実はいつも一つ！/ Always, there's only one truth!