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
parent
31a1f5b94e
commit
26f6a21308
|
@ -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:
|
||||||
|
|
|
@ -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
|
||||||
|
|
Loading…
Reference in New Issue