Add option to disable registering new nodes with duplicate IPs

Is your feature request related to a problem? Please describe.

Kubernetes requires that all nodes have a unique name, but does not enforce a unique constraint on node addresses. Kubernetes itself makes no assumptions about network configuration; it may be possible that nodes legitimately have the same short hostname, private IP address, or so on. However, cluster components (such as CNI, embedded registry, or apiserver network proxy) that build routing tables keyed off the node address may not behave properly if multiple nods have the same addresses registered.

Describe the solution you'd like

K3s should have the option to reject signing of new kubelet certificates, and configure the embedded CCM to refuse to set additional node addresses, if the addresses requested by the new node are already assigned to another node in the cluster. As this would be a breaking change, and would likely make the with-node-id option non-functional, this should be an optional control that is off by default.

Describe alternatives you've considered

Enforce the restrictions at Node resource creation/modification time via KubeWarden or other external policy engine.

Additional context

In the absence of a cloud infrastructure provider to supply authoritative, unique node addresses, K3s includes an embedded cloud controller that allows administrators to configure nodes that assert their own external IPs and hostnames. Internal IPs can be auto-detected by the kubelet, or supplied by the administrator. While it may be an error on the part of the administrator to join multiple nodes with duplicate IPs, and it may cause unexpected behavior, there are no prohibitions against doing so.

K3s intentionally supports joining nodes with duplicate addresses, via the with-node-id option. This appends a random string to the end of the node name, so that nodes with duplicate addresses can join the cluster without conflicting. This is commonly used in environments using dynamic IP assignment, where addresses and hostnames may be reused before the old nodes are removed from from the cluster.

Signing kubelet-serving certificates with node-provided IPs is also by design; the kubelet serving certificate must be valid for the nodes IPs for metrics, pod logs, and other such requests that target endpoints hosted by the kubelet. Note that the address type used to reach the kubelet is controlled by the apiserver's kubelet-preferred-address-types flag, but Kubernetes does not enforce uniqueness for any of the possible values.