-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cgroups v2 strategy #292
Comments
As a data point, Docker in F31 doesn't run on cgroups v2 and the problem has been rejected as a Fedora release blocker. |
FCOS is likely to ship with CGroupsV1 to start, since most of the containerization ecosystem isn't yet ready for V2. Pass the `systemd.unified_cgroup_hierarchy=0` karg to enable this. This should at least allow podman Kola tests to pass. For more information, see: coreos/fedora-coreos-tracker#292
@rhatdan We discussed this during the last community meeting and agreed that shipping with v1 for now is the safer course of action. One question we had was: is there anything we can do now to make migration to v2 easier later? |
Switching to crun by default, would help. But I guess you should shift on Fedora 32. Since we have made the change, we are witnessing a lot of movement in runc and k8s towards cgroup v2. |
FCOS is likely to ship with CGroupsV1 to start, since most of the containerization ecosystem isn't yet ready for V2. Pass the `systemd.unified_cgroup_hierarchy=0` karg to enable this. This should at least allow podman Kola tests to pass. For more information, see: coreos/fedora-coreos-tracker#292
FCOS is likely to ship with CGroupsV1 to start, since most of the containerization ecosystem isn't yet ready for V2. Pass the `systemd.unified_cgroup_hierarchy=0` karg to enable this. This should at least allow podman Kola tests to pass. For more information, see: coreos/fedora-coreos-tracker#292
We found an issue with the current approach specifically when it comes to handling the F30->F31 update. We'll proceed with trying the workaround described in that issue comment. |
We found an issue [1] with our cgroups v2 strategy [2]. We need to revert the recent promotions (that move us to F31) and do a new release of F30 content with a slight modification. See the proposed solution in the issue comment. - Revert "tree: promote changes from testing-devel at 20e1222" - This reverts commit 0d8e188. - Revert "manifest.yaml: bump to Fedora 31" - This reverts commit c11e08f. - Revert "manifest.yaml: adapt for new path to fedora-coreos.yaml" - This reverts commit 01850ff. [1] coreos/fedora-coreos-streams#26 (comment) [2] coreos/fedora-coreos-tracker#292
In f31, the default cgroup changed to v2. However, we've decided to stay on v1 for the time being. Thus, we don't want older nodes upgrading to f31 to be forced into v2. Add a tiny service which just scans the BLS configs and injects the `systemd.unified_cgroup_hierarchy` karg as needed. For more information, see: coreos/fedora-coreos-tracker#292 coreos/fedora-coreos-streams#26 (comment)
We found an issue [1] with our cgroups v2 strategy [2]. We need to revert the recent promotions (that move us to F31) and do a new release of F30 content with a slight modification. See the proposed solution in the issue comment. - Revert "tree: promote changes from testing-devel at 20e1222" - This reverts commit 0d8e188. - Revert "manifest.yaml: bump to Fedora 31" - This reverts commit c11e08f. - Revert "manifest.yaml: adapt for new path to fedora-coreos.yaml" - This reverts commit 01850ff. [1] coreos/fedora-coreos-streams#26 (comment) [2] coreos/fedora-coreos-tracker#292
In f31, the default cgroup changed to v2. However, we've decided to stay on v1 for the time being. Thus, we don't want older nodes upgrading to f31 to be forced into v2. Add a tiny service which just scans the BLS configs and injects the `systemd.unified_cgroup_hierarchy` karg as needed. For more information, see: coreos/fedora-coreos-tracker#292 coreos/fedora-coreos-streams#26 (comment)
In f31, the default cgroup changed to v2. However, we've decided to stay on v1 for the time being. Thus, we don't want older nodes upgrading to f31 to be forced into v2. Add a tiny service which just scans the BLS configs and injects the `systemd.unified_cgroup_hierarchy` karg as needed. For more information, see: coreos/fedora-coreos-tracker#292 coreos/fedora-coreos-streams#26 (comment)
In the meeting from a few weeks ago we said:
I opened coreos/butane#57 for the remaining items. |
Before stepping into docs and fcct, it is unclear to me how we plan to tackle kargs configuration at the Ignition/initramfs level. Right now we can arrange things (via Ignition) so that the BLS is changed after the first boot, but that requires a reboot to apply (thus is doesn't affect the first boot). |
Yup, that's https://github.com/coreos/ignition-dracut/issues/81. The status on that is essentially:
|
with containerd/containerd#3726 merging, do we need to look at this again? |
Yeah. It needs to land in upstream releases and that needs to hit Fedora so we can pick it up, not sure if it will happen for fedora 33. Anybody know what the kubernetes cgroups v2 status is now? |
the plan is to have cgroup v2 support in Kubernetes 1.19 |
Per a message[1] to the Fedora CoreOS mailing list from @Conan-Kudo, Docker/Moby 20.10 now has cgroups v2 support. |
@olivierlemasle seems to be Fedora RPM maintainer. Hi Olivier, |
All we need to do is to make the associated karg be specific to `testing-devel` by uplisting it to `image.yaml`. Then `next-devel` will naturally shed it when `image-base.yaml` gets synced over. See: coreos/fedora-coreos-tracker#292
* Fedora CoreOS is beginning to switch from cgroups v1 to cgroups v2 by default, which changes the sysfs hierarchy * This will be needed when using a Fedora Coreos OS image that enables cgroups v2 (`next` stream as of this writing) Rel: coreos/fedora-coreos-tracker#292
* Fedora CoreOS is beginning to switch from cgroups v1 to cgroups v2 by default, which changes the sysfs hierarchy * This will be needed when using a Fedora Coreos OS image that enables cgroups v2 (`next` stream as of this writing) Rel: coreos/fedora-coreos-tracker#292
* Fedora CoreOS is beginning to switch from cgroups v1 to cgroups v2 by default, which changes the sysfs hierarchy * This will be needed when using a Fedora Coreos OS image that enables cgroups v2 (`next` stream as of this writing) Rel: coreos/fedora-coreos-tracker#292
Adjust the kernel arguments so that we're now using cgroups v2 in our testing-devel (and subsequently, testing and stable) stream(s). Context: coreos/fedora-coreos-tracker#292
Looks like everything is in place and we've waited a sufficient amount of time since the email was sent out. Moving forward: coreos/fedora-coreos-config#1033 |
Adjust the kernel arguments so that we're now using cgroups v2 in our testing-devel (and subsequently, testing and stable) stream(s). Context: coreos/fedora-coreos-tracker#292
It's not very realistic, but as a sanity-check, I created a simple podman |
The fix for this went into testing stream release |
The fix for this went into stable stream release |
* On Fedora CoreOS, Cilium cross-node service IP load balancing stopped working for a time (first observable as CoreDNS pods located on worker nodes not being able to reach the kubernetes API service 10.3.0.1). This turned out to have two parts: * Fedora CoreOS switched to cgroups v2 by default. In our early testing with cgroups v2, Calico (default) was used. With the cgroups v2 change, SELinux policy denied some eBPF operations. Since fixed in all Fedora CoreOS channels * Cilium requires new mounts to support cgroups v2, which are added here * coreos/fedora-coreos-tracker#292 * coreos/fedora-coreos-tracker#881 * cilium/cilium#16259
* On Fedora CoreOS, Cilium cross-node service IP load balancing stopped working for a time (first observable as CoreDNS pods located on worker nodes not being able to reach the kubernetes API service 10.3.0.1). This turned out to have two parts: * Fedora CoreOS switched to cgroups v2 by default. In our early testing with cgroups v2, Calico (default) was used. With the cgroups v2 change, SELinux policy denied some eBPF operations. Since fixed in all Fedora CoreOS channels * Cilium requires new mounts to support cgroups v2, which are added here * coreos/fedora-coreos-tracker#292 * coreos/fedora-coreos-tracker#881 * cilium/cilium#16259
* On Fedora CoreOS, Cilium cross-node service IP load balancing stopped working for a time (first observable as CoreDNS pods located on worker nodes not being able to reach the kubernetes API service 10.3.0.1). This turned out to have two parts: * Fedora CoreOS switched to cgroups v2 by default. In our early testing with cgroups v2, Calico (default) was used. With the cgroups v2 change, SELinux policy denied some eBPF operations. Since fixed in all Fedora CoreOS channels * Cilium requires new mounts to support cgroups v2, which are added here * coreos/fedora-coreos-tracker#292 * coreos/fedora-coreos-tracker#881 * cilium/cilium#16259
* On Fedora CoreOS, Cilium cross-node service IP load balancing stopped working for a time (first observable as CoreDNS pods located on worker nodes not being able to reach the kubernetes API service 10.3.0.1). This turned out to have two parts: * Fedora CoreOS switched to cgroups v2 by default. In our early testing with cgroups v2, Calico (default) was used. With the cgroups v2 change, SELinux policy denied some eBPF operations. Since fixed in all Fedora CoreOS channels * Cilium requires new mounts to support cgroups v2, which are added here * coreos/fedora-coreos-tracker#292 * coreos/fedora-coreos-tracker#881 * cilium/cilium#16259
* Fedora CoreOS is beginning to switch from cgroups v1 to cgroups v2 by default, which changes the sysfs hierarchy * This will be needed when using a Fedora Coreos OS image that enables cgroups v2 (`next` stream as of this writing) Rel: coreos/fedora-coreos-tracker#292
* On Fedora CoreOS, Cilium cross-node service IP load balancing stopped working for a time (first observable as CoreDNS pods located on worker nodes not being able to reach the kubernetes API service 10.3.0.1). This turned out to have two parts: * Fedora CoreOS switched to cgroups v2 by default. In our early testing with cgroups v2, Calico (default) was used. With the cgroups v2 change, SELinux policy denied some eBPF operations. Since fixed in all Fedora CoreOS channels * Cilium requires new mounts to support cgroups v2, which are added here * coreos/fedora-coreos-tracker#292 * coreos/fedora-coreos-tracker#881 * cilium/cilium#16259
All we need to do is to make the associated karg be specific to `testing-devel` by uplisting it to `image.yaml`. Then `next-devel` will naturally shed it when `image-base.yaml` gets synced over. See: coreos/fedora-coreos-tracker#292
Adjust the kernel arguments so that we're now using cgroups v2 in our testing-devel (and subsequently, testing and stable) stream(s). Context: coreos/fedora-coreos-tracker#292
All we need to do is to make the associated karg be specific to `testing-devel` by uplisting it to `image.yaml`. Then `next-devel` will naturally shed it when `image-base.yaml` gets synced over. See: coreos/fedora-coreos-tracker#292
Adjust the kernel arguments so that we're now using cgroups v2 in our testing-devel (and subsequently, testing and stable) stream(s). Context: coreos/fedora-coreos-tracker#292
Fedora 31 is planning to switch to cgroups v2 by default. The explicit goal is for Fedora to drive the leading edge, encouraging components that don't fully support v2 to do so. However, this may not yet be the best choice for Fedora CoreOS, which aims to provide broad and reliable container support for production environments.
We have the ability to make a different decision here than the rest of Fedora. However, if we ship the stable release with cgroups v1, we'll need to think about compatibility constraints when/if we later switch to v2.
We should define a strategy for the cgroups v2 transition.
The text was updated successfully, but these errors were encountered: