On 7/19/23 08:59, Neal Gompa wrote:
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!
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.
