Validate that IP addresses for ControlPlane and StaticWorkers are different

[kron4eg]

Which issue(s) this PR fixes:
Fixes #2632

What type of PR is this?
/kind api-change

Special notes for your reviewer:

Does this PR introduce a user-facing change? Then add your Release Note here:

[ACTION REQUIRED] KubeOne is now validating that IP addresses and hostnames provided for control plane nodes and static worker nodes are different. In other words, it's not possible to use the same machine both as a control plane node and a static worker node. This behavior has never been supported by KubeOne; if you want a control plane node that can schedule any pod, you can provision it as a control plane node and remove the control plane taint (`node-role.kubernetes.io/control-plane:NoSchedule`).

Documentation:

NONE

[xmudrii]

@kron4eg What if we add public and private addresses, and hostnames, of CP and static worker nodes to two different sets, and then compare sets? That seems like a great way to prevent any possible combination of what can go wrong, as long as we find any intersection, we error out.

[kron4eg]

@kron4eg What if we add public and private addresses, and hostnames, of CP and static worker nodes to two different sets, and then compare sets? That seems like a great way to prevent any possible combination of what can go wrong, as long as we find any intersection, we error out.

Hostnames are optional and may be absent at the time when validation is running. That's why I didn't included them in the check. Given nested for loop almost exactly the same as sets but without fancy APIs/functions, except one thing. It point to the exact index of the problematic static worker with with .Index() function. Which is not possible with sets.

[xmudrii]

Hostnames are optional and may be absent at the time when validation is running. That's why I didn't included them in the check.

That's true, but if we know them, it's useful to do the validation, and with sets this is very easy.

Given nested for loop almost exactly the same as sets but without fancy APIs/functions, except one thing.

They don't function the exactly same, for example, you might "hack" around by inverting public and private addresses. This and some other cases are much easier to catch by doing the intersection.

It point to the exact index of the problematic static worker with with .Index() function. Which is not possible with sets.

This is nice, but IMO it's also enough just to point out to what value is conflicting and you can do that with intersect.

[kron4eg]

TBH I don't want to change the thing "just because" with loosing some of the info. There has to be a good reason for that and I don't see sets as one.

[xmudrii]

@kron4eg Can we at least include the information what's the conflicting IP address? I find that much more valuable compared to the index.

[kron4eg]

@kron4eg Can we at least include the information what's the conflicting IP address? I find that much more valuable compared to the index.

sure, and as a bonus optional validation on the hostname (excluding empty case).

[xmudrii]

/lgtm
/approve

[kubermatic-bot]

LGTM label has been added.

Git tree hash: 23d1440fc464b6a50de1805cc0cd04d9812c3047

[kubermatic-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: xmudrii

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [xmudrii]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[xmudrii]

/release-note-edit

[ACTION REQUIRED] KubeOne is now validating that IP addresses and hostnames provided for control plane nodes and static worker nodes are different. In other words, it's not possible to use the same machine both as a control plane node and a static worker node. This behavior has never been supported by KubeOne; if you want a control plane node that can schedule any pod, you can provision it as a control plane node and remove the control plane taint (`node-role.kubernetes.io/control-plane:NoSchedule`).