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

[Daniel Walsh]

On 7/19/23 08:59, Neal Gompa wrote:
> On Wed, Jul 19, 2023 at 8:52 AM Luca Boccassi <luca.boccassi at gmail.com> wrote:
>> 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?
> 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!
>
I believe it is definitely time to remove support for it. Cgroupv1 never 
worked well, and this is a chance to move forward with a well supported 
solution.