kubeadm: update references of "master" label/taint for 1.24

In 1.24 kubeadm will:
- stop using the "master" label on CP nodes.
- start tainting CP nodes with both "master" and "control-plane" taints.

In 1.25 the "master" taint will be removed.

Adjust references of the "master" label/taint to the above.
This commit is contained in:
Lubomir I. Ivanov
2022-01-18 18:08:20 +02:00
parent aef172862a
commit 806518df13
9 changed files with 49 additions and 29 deletions
@@ -285,26 +285,30 @@ for `kubeadm`.
### Control plane node isolation
By default, your cluster will not schedule Pods on the control-plane node for security
reasons. If you want to be able to schedule Pods on the control-plane node, for example for a
single-machine Kubernetes cluster for development, run:
By default, your cluster will not schedule Pods on the control plane nodes for security
reasons. If you want to be able to schedule Pods on the control plane nodes,
for example for a single machine Kubernetes cluster, run:
```bash
kubectl taint nodes --all node-role.kubernetes.io/master-
kubectl taint nodes --all node-role.kubernetes.io/control-plane- node-role.kubernetes.io/control-master-
```
With output looking something like:
The output will look something like:
```
node "test-01" untainted
taint "node-role.kubernetes.io/master:" not found
taint "node-role.kubernetes.io/master:" not found
...
```
This will remove the `node-role.kubernetes.io/master` taint from any nodes that
have it, including the control-plane node, meaning that the scheduler will then be able
This will remove the `node-role.kubernetes.io/control-plane` and
`node-role.kubernetes.io/master` taints from any nodes that have them,
including the control plane nodes, meaning that the scheduler will then be able
to schedule Pods everywhere.
{{< note >}}
The `node-role.kubernetes.io/master` taint is deprecated and kubeadm will stop using it in version 1.25.
{{< /note >}}
### Joining your nodes {#join-nodes}
The nodes are where your workloads (containers and Pods, etc) run. To add new nodes to your cluster do the following for each machine:
@@ -351,7 +351,7 @@ A known solution is to patch the kube-proxy DaemonSet to allow scheduling it on
nodes regardless of their conditions, keeping it off of other nodes until their initial guarding
conditions abate:
```
kubectl -n kube-system patch ds kube-proxy -p='{ "spec": { "template": { "spec": { "tolerations": [ { "key": "CriticalAddonsOnly", "operator": "Exists" }, { "effect": "NoSchedule", "key": "node-role.kubernetes.io/master" } ] } } } }'
kubectl -n kube-system patch ds kube-proxy -p='{ "spec": { "template": { "spec": { "tolerations": [ { "key": "CriticalAddonsOnly", "operator": "Exists" }, { "effect": "NoSchedule", "key": "node-role.kubernetes.io/master" }, { "effect": "NoSchedule", "key": "node-role.kubernetes.io/control-plane" } ] } } } }'
```
The tracking issue for this problem is [here](https://github.com/kubernetes/kubeadm/issues/1027).