feat: coredns node uninitialized toleration

[sergelogvinov]

Launch CoreDNS even if the node is not initialized. Network is ready already, but CCM didn't finish their job.
CCM needs the dns resolver to reach the talos-api, but CoreDNS stack in toleration condition.
I didn't catch this lock before, because I used my own coredns deploy....

I remove the CriticalAddonsOnly key. It was from kubeadm bootstrap process.
We do not use it.

Pull Request

What? (description)

Why? (reasoning)

Acceptance

Please use the following checklist:

• you linked an issue (if applicable)
• you included tests (if applicable)
• you ran conformance (make conformance)
• you formatted your code (make fmt)
• you linted your code (make lint)
• you generated documentation (make docs)
• you ran unit-tests (make unit-tests)

See make help for a description of the available targets.

[frezbo]

isn;t ccm's deployed with hostnetwork?

[sergelogvinov]

It can be launch in both mode - with or without hostnetwork. In first case, make sense to think about port overlapping, something can use the same ports already...

But all modes do not solve service resolving inside the kubernetes...
For example - cilium uses IP, or external host name to reach the kubernetes api (k8sServiceHost value in helm chart). CoreDNS does the same in a few cases (endpoint, kubeconfig values in config).

Boot process:
node created with tenants node.kubernetes.io/network-unavailable, node.cloudprovider.kubernetes.io/uninitialized -> after successful launch CNI, node has node.cloudprovider.kubernetes.io/uninitialized (network ready already) -> coredns can starts now with CCM -> CCM resolve hosts/resources, do some job and remove uninitialized tenant -> Node fully ready.

[smira]

lgtm, CriticalAddonsOnly looks like a leftover from really ancient times

[smira]

/ok-to-test

[smira]

/m