cgroup v1 maintenance mode

[harche]

Documentation for transitioning cgroup v1 in maintenance mode.

[netlify]

👷 Deploy Preview for kubernetes-io-vnext-staging processing.

Name	Link
🔨 Latest commit	0f9497e
🔍 Latest deploy log	https://app.netlify.com/sites/kubernetes-io-vnext-staging/deploys/6696964b7f4b1f0008fb2c74

[netlify]

✅ Pull request preview available for checking

Built without sensitive environment variables

Name	Link
🔨 Latest commit	186bdf9
🔍 Latest deploy log	https://app.netlify.com/sites/kubernetes-io-main-staging/deploys/669693c612a70800087d32a0
😎 Deploy Preview	https://deploy-preview-46801--kubernetes-io-main-staging.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[hacktivist123]

Hello @harche 👋 please take a look at Documenting for a release - PR Ready for Review to get your PR ready for review before Tuesday, July 16th, 2024 18:00 PST. Thank you!

[Princesso]

Hi @harche, a gentle reminder that tomorrow is the deadline for having your Docs PR ready for review. Please take a look at Documenting for a release - PR Ready for Review to get your PR ready for review before tomorrow, Tuesday, July 16th, 2024 18:00 PST.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign salaxander for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• content/en/docs/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[harche]

/hold till kubernetes/kubernetes#126031 merges.

[harche]

@Princesso @hacktivist123 this PR is ready for review. Thanks.

[haircommander]

You may want to link something to what cgroups are before diving into the details. I'm sure there's content on the website already, but a quick link will give the audience the background needed quickly

[tengqm]

My feeling is that this content is more suitable to be a blog post. It is not a concept explanation and it is not a task showing users how to do this switching.

[harche]

@tengqm in the section ## Failing on cgroup v1 Nodes at the bottom I tried to explain how to use newly added kubelet flag.

[harche]

Also the section ## How to Determine the cgroup Version Used by Your Nodes explains how to use newly added kubelet metric.

[tengqm]

@harche There are two options for this piece of information as I see it. You can create a blog page introducing the work behind this cgroup v1->v2 change. For example, what does cgroups mean, why v1 is put into maintenance mode, why v2 is better than v1, so on and so forth. You can provide suggestions how to check the version used and how to make the change in the blog.

Another option is to add a task page. The task is about switch from cgroup v1 to v2, period. The task is not about putting v1 into maintenance mode. In a task page, you are talking to the users, not the developers. You can still provide some simple English explanation about the background, but you may want to skip the developer's story.

[hacktivist123]

@harche There are two options for this piece of information as I see it. You can create a blog page introducing the work behind this cgroup v1->v2 change. For example, what does cgroups mean, why v1 is put into maintenance mode, why v2 is better than v1, so on and so forth. You can provide suggestions how to check the version used and how to make the change in the blog.

Another option is to add a task page. The task is about switch from cgroup v1 to v2, period. The task is not about putting v1 into maintenance mode. In a task page, you are talking to the users, not the developers. You can still provide some simple English explanation about the background, but you may want to skip the developer's story.

I agree with this @harche, thanks for your insight @tengqm! I'd say we stick to option one.

However @tengqm do you think it would make sense to have the proposed blog post linked somewhere in the docs?

[Princesso]

Hi @harche, I see this PR is already being reviewed. Can you move it out of Drafts? Thank you!

[tengqm]

However @tengqm do you think it would make sense to have the proposed blog post linked somewhere in the docs?

It is totally fine to have docs linked to blogs and vice versa.

[sftim]

@harche I notice that:

• the PR doesn't build
• there's no PR description

You should fix both of these details; it will help reviewers if you do.

[windsonsea]

Suggested change

	--- title: Moving cgroup v1 support into maintenance mode
	min-kubernetes-server-version: 1.31 content_type: task weight: 90 ---
	---
	title: Moving cgroup v1 support into maintenance mode
	min-kubernetes-server-version: 1.31
	content_type: task
	weight: 90
	---

[harche]

Thanks for that pointer.

[harche]

@harche There are two options for this piece of information as I see it. You can create a blog page introducing the work behind this cgroup v1->v2 change. For example, what does cgroups mean, why v1 is put into maintenance mode, why v2 is better than v1, so on and so forth. You can provide suggestions how to check the version used and how to make the change in the blog.

Another option is to add a task page. The task is about switch from cgroup v1 to v2, period. The task is not about putting v1 into maintenance mode. In a task page, you are talking to the users, not the developers. You can still provide some simple English explanation about the background, but you may want to skip the developer's story.

@tengqm Switching from cgroup v1 to v2 is beyond the scope of Kubernetes itself; it’s something that OS administrators need to handle.

We haven't added any cgroup version-specific features; instead, we've put cgroup v1 into maintenance mode to encourage users to transition to cgroup v2.

Given the feedback I've received so far, would it be acceptable to close this PR and move all its content to a blog post (as part of this PR)?

[tengqm]

My suggestion would be drafting a blog post for this.

[hacktivist123]

Hello @harche 👋! I'm reaching out from the Docs team. Just checking in as we approach Docs Freeze on Tuesday, July 30th 18:00 PDT. This documentation appears to still be under review. To meet the Docs Freeze, this PR must have a technical review as well as lgtm and approve labels applied, without any unaddressed comments or concerns from SIG Docs. The status of this enhancement is marked as at risk for docs freeze. Thank you

[kannon92]

Should we mention another way to determine cgroup? We introduce this metric in 1.31 so it may be misleading since this metric isn't in every supported version of kubernetes.

[harche]

My suggestion would be drafting a blog post for this.

Alright, based on the feedback so far I am closing this PR and would rather focus on a blog post PR - #47069

/close

[k8s-ci-robot]

@harche: Closed this PR.

In response to this:

My suggestion would be drafting a blog post for this.

Alright, based on the feedback so far I am closing this PR and would rather focus on a blog post PR - #47069

/close

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.