Skip to content

[KEP-5573]: follows up from review #5646

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.

Sign up for GitHub

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

Merged
merged 1 commit into from
Oct 13, 2025
Merged

[KEP-5573]: follows up from review #5646

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 12 additions & 4 deletions ...node/5573-cgroup-v1-unsupported/README.md → .../sig-node/5573-remove-cgroup-v1/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -156,9 +156,13 @@ The latest release of debian "Trixie" is using [systemd 257](https://packages.de
6. **Remove cgroup v1 code**: Removing the code is the next logic step once we stop testing it. This will clean up
the codebase.

7. **Update system-validators**: system-validator should react correctly to kubelet not starting on a cgroup v1 node. See [issue](https://github.com/kubernetes/system-validators/issues/58) for more details.

### Non-Goals

NA.
In this KEP, we will focus on the kubelet related work to remove cgroup v1.
Projects like minikube, kubeadm, kubespray and others may need work to support this flag going to false
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

kubeadm already supports customizing kubelet config so I'm not sure if anything needs to be done here, updates to the preflight checks? docs?

kubeadm is a little bit weird because it's in-tree and used for release-blocking signal (similarly if the node_e2e or kube-up scripts didn't work we'd have a problem), I think calling out out-of-tree projects as out of scope is at least reasonable.

It's not super great to release k/k with the release binaries out of sync.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The rest of the diff LGTM, not sure about this part.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not super great to release k/k with the release binaries out of sync.

I don't follow what you mean here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

kubeadm already supports customizing kubelet config so I'm not sure if anything needs to be done here, updates to the preflight checks? docs?

#5574 (comment)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't follow what you mean here.

Saying "this kep won't wait for another core release binary to be ready" is a little different from "we're not going to block on out of tree projects updating", kubeadm is part of the core kubernetes release. We shouldn't release a broken state.

#5574 (comment)

I see ... commented

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

kubeadm is a little bit weird because it's in-tree and used for release-blocking signal (similarly if the node_e2e or kube-up scripts didn't work we'd have a problem), I think calling out out-of-tree projects as out of scope is at least reasonable.

That's true and we also have an issue to move it out which is not updated for a long time. #1424

https://github.com/kubernetes/system-validators/blob/a7fadf67da1228984480d7e8dd9c8ae39803a442/validators/cgroup_validator_linux.go#L117

		warns = append(warns, errors.New("cgroups v1 support is in maintenance mode, please migrate to cgroups v2"))

We have a warning message when cgroup v1 support went to maintenance mode.

After this change happened in kubelet, we will update it to an error IIUC. This will be tracked in kubernetes/system-validators#58.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I took a stab at addressing this. I'm not entirely sure what the goal is for system-validators but I call that out as a goal for this KEP.

but that is out of scope for this KEP.

## Proposal

Expand All @@ -179,6 +183,10 @@ The primary risks involve potential disruptions for users who have not yet migra
- IBM SDK Java Technology Edition Version (IBM Java): 8.0.7.15 and later
- Third-party monitoring and security agents need to support cgroup v2

3. **oom.group**: In cgroup v2, the kernel community introduced a feature to allow the Out-of-Memory (OOM) killer to terminate an entire group of processes as an indivisible unit.
- Users who need the cgroup v1 behavior can toggle `singleProcessOOMKill` to true on the kubelet config.
- This will allow the kernel to kill the process that triggers OOMs without killing the rest of the processes.

**Mitigations**:

- Provide comprehensive migration documentation and guidance
Expand Down Expand Up @@ -224,7 +232,7 @@ klog.Warning("cgroup v1 detected. cgroup v1 support has been transitioned into m
To (deprecated):

```golang
klog.Warning("cgroup v1 detected. cgroup v1 support is deprecated and will be removed in a future release. Please migrate to cgroup v2. More information at https://git.k8s.io/enhancements/keps/sig-node/5573-cgroup-v1-unsupported")
klog.Warning("cgroup v2 detected. cgroup v1 support is deprecated and will be removed in a future release. Please migrate to cgroup v2. More information at https://git.k8s.io/enhancements/keps/sig-node/5573-remove-cgroup-v1")
```

Similar updates will be made to corresponding events.
Expand All @@ -248,7 +256,7 @@ Other lanes will be removed but we will continue supporting this lane until we f
### Removal of cgroup v1

<UNRESOLVED @haircommander>
Once all supported releases of Kubernetes have `FailCGroupV1` set to true, we can begin the removal of the cgroup v1 support.
Once all supported releases of Kubernetes have `FailCgroupV1` set to true, we can begin the removal of the cgroup v1 support.

In this section, we should call the places where we are going to remove cgroup v1.
</UNRESOLVED>
Expand Down Expand Up @@ -558,4 +566,4 @@ express the idea and why it was not acceptable.

3. **Opt-in cgroup v2**: Require explicit configuration to enable cgroup v2 instead of disabling cgroup v1 by default. This was ruled out because it doesn't provide clear signals about the deprecation path and slows adoption of the preferred technology.

4. **Feature gate approach**: Use a feature gate instead of a kubelet flag. This was ruled out because kubelet flags provide more direct control over the behavior and are more appropriate for this type of configuration change.
4. **Feature gate approach**: Use a feature gate instead of a kubelet flag. This was ruled out because kubelet flags provide more direct control over the behavior and are more appropriate for this type of configuration change.
0 ...-node/5573-cgroup-v1-unsupported/kep.yaml → keps/sig-node/5573-remove-cgroup-v1/kep.yaml
View file
Open in desktop
File renamed without changes.