From 40b013b63f28fbaa5a0a5dddb65f56bba152b249 Mon Sep 17 00:00:00 2001 From: Sergey Kanzhelev Date: Fri, 10 Sep 2021 17:00:32 +0000 Subject: [PATCH] Node re-registration required to update the node labels --- content/en/docs/concepts/architecture/nodes.md | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/content/en/docs/concepts/architecture/nodes.md b/content/en/docs/concepts/architecture/nodes.md index 1d4f6455b7..a57d47219e 100644 --- a/content/en/docs/concepts/architecture/nodes.md +++ b/content/en/docs/concepts/architecture/nodes.md @@ -72,7 +72,8 @@ The name of a Node object must be a valid The [name](/docs/concepts/overview/working-with-objects/names#names) identifies a Node. Two Nodes cannot have the same name at the same time. Kubernetes also assumes that a resource with the same name is the same object. In case of a Node, it is implicitly assumed that an instance using the -same name will have the same state (e.g. network settings, root disk contents). This may lead to +same name will have the same state (e.g. network settings, root disk contents) +and attributes like node labels. This may lead to inconsistencies if an instance was modified without changing its name. If the Node needs to be replaced or updated significantly, the existing Node object needs to be removed from API server first and re-added after the update. @@ -98,6 +99,21 @@ When the [Node authorization mode](/docs/reference/access-authn-authz/node/) and [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) are enabled, kubelets are only authorized to create/modify their own Node resource. +{{< note >}} +As mentioned in the [Node name uniqueness](#node-name-uniqueness) section, +when Node configuration needs to be updated, it is a good practice to re-register +the node with the API server. For example, if the kubelet being restarted with +the new set of `--node-labels`, but the same Node name is used, the change will +not take an effect, as labels are being set on the Node registration. + +Pods already scheduled on the Node may misbehave or cause issues if the Node +configuration will be changed on kubelet restart. For example, already running +Pod may be tainted against the new labels assigned to the Node, while other +Pods, that are incompatible with that Pod will be scheduled based on this new +label. Node re-registration ensures all Pods will be drained and properly +re-scheduled. +{{< /note >}} + ### Manual Node administration You can create and modify Node objects using