-
Notifications
You must be signed in to change notification settings - Fork 15.2k
docs: document kubelet cgroup driver detection from the runtime #42160
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
Changes from 3 commits
c50c151
7e208b0
0d2962b
fa73830
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -157,6 +157,12 @@ Starting with v1.22 and later, when creating a cluster with kubeadm, if the user | |
| the `cgroupDriver` field under `KubeletConfiguration`, kubeadm defaults it to `systemd`. | ||
| {{< /note >}} | ||
|
|
||
| In Kubernetes {{< skew currentVersion >}}, with the `KubeletCgroupDriverFromCRI` | ||
| [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) | ||
| enabled and a container runtime that supports the `RuntimeConfig` CRI RPC, | ||
| the kubelet automatically detects the appropriate cgroup driver from the runtime, | ||
| and ignores the `cgroupDriver` setting within the kubelet configuration. | ||
|
|
||
| If you configure `systemd` as the cgroup driver for the kubelet, you must also | ||
| configure `systemd` as the cgroup driver for the container runtime. Refer to | ||
| the documentation for your container runtime for instructions. For example: | ||
|
|
@@ -251,6 +257,10 @@ sudo systemctl restart containerd | |
| When using kubeadm, manually configure the | ||
| [cgroup driver for kubelet](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/#configuring-the-kubelet-cgroup-driver). | ||
|
|
||
| In Kubernetes {{< skew currentVersion >}}, you can enable automatic detection of the | ||
|
||
| cgroup driver as an alpha feature. See [systemd cgroup driver](#systemd-cgroup-driver) | ||
| for more details. | ||
|
|
||
| #### Overriding the sandbox (pause) image {#override-pause-image-containerd} | ||
|
|
||
| In your [containerd config](https://github.com/containerd/containerd/blob/main/docs/cri/config.md) you can overwrite the | ||
|
|
@@ -292,6 +302,10 @@ You should also note the changed `conmon_cgroup`, which has to be set to the val | |
| cgroup driver configuration of the kubelet (usually done via kubeadm) and CRI-O | ||
| in sync. | ||
|
|
||
| In Kubernetes {{< skew currentVersion >}}, you can enable automatic detection of the | ||
|
||
| cgroup driver as an alpha feature. See [systemd cgroup driver](#systemd-cgroup-driver) | ||
| for more details. | ||
|
|
||
| For CRI-O, the CRI socket is `/var/run/crio/crio.sock` by default. | ||
|
|
||
| #### Overriding the sandbox (pause) image {#override-pause-image-cri-o} | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -36,6 +36,11 @@ driver of the kubelet. | |
| {{< note >}} | ||
| In v1.22 and later, if the user does not set the `cgroupDriver` field under `KubeletConfiguration`, | ||
| kubeadm defaults it to `systemd`. | ||
|
|
||
| In Kubernetes {{< skew currentVersion >}}, you can enable automatic detection of the | ||
|
||
| cgroup driver as an alpha feature. | ||
| See [systemd cgroup driver](/docs/setup/production-environment/container-runtimes/#systemd-cgroup-driver) | ||
| for more details. | ||
| {{< /note >}} | ||
|
|
||
| A minimal example of configuring the field explicitly: | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suppose we are in v1.29 now, the above line will be rendered into something like
"In Kubernetes 1.29, with the
KubeletCgroupDriverFromCRI".Is this statement still appropriate?
Suppose we are in v1.34 now and the feature gate has been GA'ed and removed,
the above line will be rendered into something like
"In Kubernetes 1.34, with the
KubeletCgroupDriverFromCRI".Is this statement still appropriate?
Clearly stating that this feature is in Alpha starting 1.28 is good enough.
Why do we use the
skewshortcode the make this release number a moving target?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm indifferent on this, can change it to v1.29. This (
In Kubernetes {{< skew currentVersion >}}) was something that @sftim suggested in one of his earlier comments so I took it from there.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When we change Kubernetes, we should remove the docs. If we don't trust ourselves to do that, I would focus on fixing that lack of trust.
If we could trust the release docs process, I think this change would be fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a contributor I'm inclined to agree with @sftim about the docs process here. Especially with a KEP involved, the process should ensure that the documentation is changed when the feature is moved to beta and later GA (or removed before graduating further). WDYT @tengqm?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Per #42160 (comment), let's follow the path of least risk to the release, at least for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
K, I changed this now to
In Kubernetes v1.28, ...(not toStarting with v1.28 ...as per #42160 (comment))PTAL @sftim @tengqm