Read cluster facts from the cluster instead of asking for them

[btriapitsyn]

Problem

Kubernetes was unusable until the operator supplied egress.dnsCIDRs by hand. requireKubernetesEgress rejects an empty list, so the provider reported itself unavailable before anything else was tried.

That value is the cluster's own DNS service address — 10.96.0.10 on kind, 10.43.0.10 on k3s, different again elsewhere. It is machine data the cluster will state on request, and:

• requiring a person to find it blocks the case Kubernetes exists for — connecting to a cluster somebody else runs;
• a wrong value breaks name resolution inside the workspace, which is very hard to trace back to this setting.

Change

The provider resolves the address from the kube-system service labelled k8s-app=kube-dns — the selector kubeadm, kind, k3s, EKS, GKE and AKS all use. It covers both addresses of a dual-stack service and rejects a headless one.

• A configured range stays authoritative and skips discovery entirely.
• When RBAC hides kube-system, the operator is asked, with a distinct code and a message naming what to request from their administrator. That is the one case the machine genuinely cannot answer.
• Discovered ranges are validated exactly as configured ones are.
• Cached per kubeconfig context with an expiry, so a cluster rebuilt under a familiar name is not answered from a stale entry.

Egress validation moves after the environment checks: discovery needs a reachable cluster, and "the cluster is unreachable" is a more actionable answer than "the egress policy is incomplete".

Also

A read-only view of kubeconfig contexts, so a surface can offer the clusters the host already knows rather than ask for a context name to be typed exactly — kubeconfig is where the industry keeps this, and it binds cluster and namespace together.

Only context names, their namespaces, and which one is current are returned. A kubeconfig also holds tokens, client certificates and server addresses; none of that belongs in a settings surface.

Validation

• Six new unit tests: discovery, dual-stack, configured-range precedence, RBAC denial, headless service, and check ordering.
• Live against two real clusters with no DNS range configured, where the provider previously refused to start at all — now reports available.