On Wed, Jul 19, 2023 at 8:52 AM Luca Boccassi <luca.bocca...@gmail.com> wrote: > > On Wed, 19 Jul 2023 at 13:45, Neal Gompa <ngomp...@gmail.com> wrote: > > > > On Thu, Jul 21, 2022 at 6:15 AM Lennart Poettering > > <lenn...@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!
