[Feature blog]: cgroup v1 deprecation#52814
Conversation
k8s-ci-robot
added
cncf-cla: yes
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
k8s-ci-robot
added
language/en
kannon92
force-pushed
the
cgroupv1-deprecation-blog-post
branch
from
626e2ca to
ad317bf
Compare
kannon92
changed the title
✅ Pull request preview available for checkingBuilt without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Pull request preview available for checkingBuilt without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
| : Version 20.3.0 or later | ||
|
|
||
| **Other runtimes** | ||
| : Check with your application runtime documentation for cgroup v2 compatibility |
There was a problem hiding this comment.
I feel that this section implies that cgroup v2 support is only important at the application runtime which in my experience migrating 100's of k8s clusters from v1 to v2 is less of an issue. Everything I'm finding are various applications that assumed a cgroup v1 file system and were reading and/or interacting directly with hardcoded v1 paths (i.e. /sys/fs/cgroup/memory/memory.usage_in_bytes).
I think it's important that users understand that they need to not only ensure they have upgraded various runtimes but, that it's also worth a cursory look to see if the code has cgroup v1 assumptions or not. Unfortunately, these can be buried within many libraries. The next section while seemingly simple, is the best for migrating. I've been shocked at how not-seamless this migration actually is in practice.
There was a problem hiding this comment.
Yea, I'm not really sure if we even need a section on this tbh. At this point, I think we could remove the runtimes and just ask that blocker for migrations to cgroup v2 be brought up?
What would you suggest?
There was a problem hiding this comment.
my vote is to keep the generic runtime section and add a new below such as 'direct cgroup application dependencies', implying that some apps might assume cgroup v1 in hardcoded logic.
There was a problem hiding this comment.
Yeah, I think it's helpful to have a list of known upgrades folks should consider. If we can make it a bit more 'in your face' that it's not just those though, then I think that's a good place to land the blog post.
| --- | ||
| layout: blog | ||
| title: "Kubernetes Deprecating cgroup v1: Completing the Transition to cgroup v2" | ||
| date: xx |
There was a problem hiding this comment.
| date: xx | |
| draft: true |
We'll initially merge this as a draft.
There was a problem hiding this comment.
| [Kubernetes SIG Node](https://github.com/kubernetes/community/tree/master/sig-node) | ||
| --- | ||
|
|
||
| Following the [transition of cgroup v1 support to maintenance mode](/blog/2024/08/14/kubernetes-1-31-moving-cgroup-v1-support-maintenance-mode/) in Kubernetes v1.31, the Kubernetes project is taking the next step in our migration to cgroup v2. Starting with Kubernetes v1.35, the kubelet will refuse to start on systems using cgroup v1 by default, and complete removal of cgroup v1 code is planned for a future release. This change aligns Kubernetes with the broader Linux ecosystem's evolution toward cgroup v2. |
There was a problem hiding this comment.
Make sure that Release Comms are on board with this and are happy to run it as a standalone article.
Did you already check in with those folks?
There was a problem hiding this comment.
Eh I'm okay to not have this as a blog. It makes my workload lighter.
But i think maybe its go to announce this.
Maybe this is better as a 1.35 blog post where we call this out. WDYT?
| author: > | ||
| [Kubernetes SIG Node](https://github.com/kubernetes/community/tree/master/sig-node) | ||
| --- | ||
|
|
There was a problem hiding this comment.
In the article introduction, make it clear that this change only applies to clusters with Linux nodes (you don't have to have any).
|
|
||
| To ensure a smooth transition, cluster administrators should: | ||
|
|
||
| 1. **Verify cgroup version**: Check if your nodes are running cgroup v1 or v2: |
There was a problem hiding this comment.
| 1. **Verify cgroup version**: Check if your nodes are running cgroup v1 or v2: | |
| 1. **Verify cgroup version**: Check if your cluster has any Linux nodes running with cgroup v1: |
| # Output: cgroup2fs = cgroup v2, tmpfs = cgroup v1 | ||
| ``` | ||
|
|
||
| 2. **Migrate host systems**: Transition nodes to cgroup v2 before upgrading Kubernetes: |
| - Configure systemd to use cgroup v2 if not already enabled | ||
| - Restart nodes to apply cgroup v2 configuration | ||
|
|
||
| 3. **Update container runtimes**: Ensure your container runtime supports cgroup v2: |
There was a problem hiding this comment.
Are we sure that this is an exhaustive list? If not, rephrase to make that clear.
| @@ -0,0 +1,144 @@ | |||
| --- | |||
| layout: blog | |||
| title: "Kubernetes Deprecating cgroup v1: Completing the Transition to cgroup v2" | |||
There was a problem hiding this comment.
Should the title mention the version v1.35?
| --- | ||
| layout: blog | ||
| title: "Kubernetes Deprecating cgroup v1: Completing the Transition to cgroup v2" | ||
| date: xx |
There was a problem hiding this comment.
|
/hold I am not sure this really needs to be a blog. I want to check with release team and see if we can include this as part of the 1.35 release blog. I think this should be maybe a paragraph rather than a full blog post. |
k8s-ci-robot
added
the
do-not-merge/hold
|
Hi @kannon92, Graziano from the v1.35 Release Comms Team here! Thank you for opening this PR for the blog post announcing the cgroup v1 deprecation to the community. Currently, this post is tracked as a "Feature Blog" for the v1.35 release, which means it is scheduled for publication after the official release (tentatively, in early January). I definitely agree that this is an important piece, and we should publish it as a stand-alone article. Regarding its publication, we have two main options:
@kannon92 , as the author of this PR, please let me know which approach you prefer. The Comms Team is flexible and open to both paths. @lmktfy cc |
|
There is an action needed if someone is still using cgroup v1 node. Due to that, I like option 1. |
| : Simplifies resource management with a single, consistent hierarchy structure. | ||
|
|
||
| **Improved Performance** | ||
| : Better scalability and reduced overhead for large-scale deployments. |
| : Better scalability and reduced overhead for large-scale deployments. | ||
|
|
||
| **Enhanced Features** | ||
| : Access to new kernel features and improvements that are only available in cgroup v2. |
There was a problem hiding this comment.
"new kernel features" and their impact on Kubernetes should be explained
| : Access to new kernel features and improvements that are only available in cgroup v2. | ||
|
|
||
| **Better Resource Control** | ||
| : More precise and predictable resource allocation and limits. |
|
/close I don't think a fully blog is necessary for this after all. |
|
@kannon92: Closed this PR. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
8 participants
Description
Add a blog post annoucing deprecation of cgroup v1.
Issue
Closes: #