kubeadm: remove mentions of the the legacy kubelet-config-x.yy

The default kubelet configuration ConfigMap that kubeadm manages
is "kubelet-config" instead of "kubelet-config-x.yy" (where x.yy
is the Kubernetes version) in 1.24.

Cleanup references to the legacy naming in kubeadm documentation.

Generated contents in content/en/docs/reference/* are not updated.
pull/31687/head
Lubomir I. Ivanov 2022-02-10 18:32:00 +02:00
parent 31a1f5b94e
commit 26f6a21308
2 changed files with 5 additions and 8 deletions

View File

@ -103,10 +103,9 @@ for more information on the individual fields.
### Workflow when using `kubeadm init` ### Workflow when using `kubeadm init`
When you call `kubeadm init`, the kubelet configuration is marshalled to disk When you call `kubeadm init`, the kubelet configuration is marshalled to disk
at `/var/lib/kubelet/config.yaml`, and also uploaded to a ConfigMap in the cluster. The ConfigMap at `/var/lib/kubelet/config.yaml`, and also uploaded to a `kubelet-config` ConfigMap in the `kube-system`
is named `kubelet-config-1.X`, where `X` is the minor version of the Kubernetes version you are namespace of the cluster. A kubelet configuration file is also written to `/etc/kubernetes/kubelet.conf`
initializing. A kubelet configuration file is also written to `/etc/kubernetes/kubelet.conf` with the with the baseline cluster-wide configuration for all kubelets in the cluster. This configuration file
baseline cluster-wide configuration for all kubelets in the cluster. This configuration file
points to the client certificates that allow the kubelet to communicate with the API server. This points to the client certificates that allow the kubelet to communicate with the API server. This
addresses the need to addresses the need to
[propagate cluster-level configuration to each kubelet](#propagating-cluster-level-configuration-to-each-kubelet). [propagate cluster-level configuration to each kubelet](#propagating-cluster-level-configuration-to-each-kubelet).
@ -137,7 +136,7 @@ If the reload and restart are successful, the normal `kubeadm init` workflow con
When you run `kubeadm join`, kubeadm uses the Bootstrap Token credential to perform When you run `kubeadm join`, kubeadm uses the Bootstrap Token credential to perform
a TLS bootstrap, which fetches the credential needed to download the a TLS bootstrap, which fetches the credential needed to download the
`kubelet-config-1.X` ConfigMap and writes it to `/var/lib/kubelet/config.yaml`. The dynamic `kubelet-config` ConfigMap and writes it to `/var/lib/kubelet/config.yaml`. The dynamic
environment file is generated in exactly the same way as `kubeadm init`. environment file is generated in exactly the same way as `kubeadm init`.
Next, `kubeadm` runs the following two commands to load the new configuration into the kubelet: Next, `kubeadm` runs the following two commands to load the new configuration into the kubelet:

View File

@ -96,9 +96,7 @@ nodes before deleting the old nodes.
### Modify the kubelet ConfigMap ### Modify the kubelet ConfigMap
- Find the kubelet ConfigMap name using `kubectl get cm -n kube-system | grep kubelet-config`. - Call `kubectl edit cm kubelet-config -n kube-system`.
- Call `kubectl edit cm kubelet-config-x.yy -n kube-system` (replace `x.yy` with
the Kubernetes version).
- Either modify the existing `cgroupDriver` value or add a new field that looks like this: - Either modify the existing `cgroupDriver` value or add a new field that looks like this:
```yaml ```yaml