talosctl: make `--nodes` optional for `bootstrap` and `kubeconfig` commands

[flokli]

I put both port tcp/50000 and tcp/6443 behind a load balancer balancing among all controlplane nodes, gave the load balancer a DNS record and added that hostname to machine.certSANs.

talosconfig' has a single endpoint configured, that hostname.

When doing the initial bootstrap, the load balancer randomly forwards the request to one of the controlplane nodes. However, talosctl now explicitly requires me to specify a node to run the bootstrap on.

I don't know upfront which node gets picked as an endpoint, I don't remember individual IPs, and don't know which controlplane nodes are already up, or which ones are still booting. ideally, the one I ended up getting connected to should be just fine ;-)

Is there a way to make the --nodes argument optional for these cases and target the node that we're connected to? Maybe we should print out the certSANs of the endpoint we're connected to. As the IPs on the network interface are automatically added there, this can be used for followup talosctl --nodes $node dmesg --follow commands to follow-up on the bootstrap status ;-)

Same logic applies to the kubeconfig command, where it's probably not even necessary to print out the cert SAN. The kubeconfig, retrieved from any controlplane node in the cluster should be fine.

[smira]

Another idea which might be more robust is to use results of cluster discovery to support aliases like :any_control_plane_node, :all_control_plane_nodes, :any_worker, etc.

[flokli]

Would this also work before talosctl bootstrap has run?

[smira]

Cluster discovery works independent of the Kubernetes when discovery service is being used, so it works before the bootstrap.

[smira]

Another idea: use "labels" (not Kubernetes Node labels, but Talos cluster member labels) to target nodes:

talosctl --label=controlplane bootstrap

[smira]

See also #5637

[smira]

talosctl get

talosctl get members shouldn't require a node as well, as this is cluster-wide resource.

We could mark such resources in ResourceDefinition as cluster-wide and make talosctl use that to make a decision.

talosctl etcd members

We can also make node optional there, as etcd members are supposed to be in sync across control plane nodes.

[github-actions[bot]]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 7 days with no activity.

[sanmai-NL]

@github-actions /reopen