[GEP-28] Report Machine.status.addresses when running without target cluster #1007
Description
How to categorize this issue?
/area ipcei
/kind enhancement
What would you like to be added:
If the MCM provider runs without a target cluster (--target-kubeconfig=none), it should report a new status field: Machine.status.addresses. The type is the same as Node.status.addresses.
If the driver returns {CreateMachine,InitializeMachine,GetMachineStatus}Response.NodeName, it should be added as an element with type=Hostname to the new status field, e.g.:
status:
addresses:
- type: Hostname
address: shoot--foo--bar-worker-z1-77fd4-7tl93{CreateMachine,InitializeMachine,GetMachineStatus}Response is extended with a new Addresses field so that the driver can return additional addresses as reported by the infrastructure API. All {CreateMachine,InitializeMachine,GetMachineStatus}Response.Addresses are merged into Machine.status.addresses.
With this, a driver can report all machine addresses, e.g., type=InternalIP or even type=ExternalIP where applicable.
Why is this needed:
With #994, MCM supports managing machines without a target cluster for the GEP-28 medium-touch scenario (gardener/gardener#2906).
To bootstrap the control plane machines, gardenadm bootstrap needs to connect to the machines via SSH to run commands and copy files.
For most cases, this will be done by creating a Bastion and proxying the node SSH connection over the bastion SSH connection.
Independent of whether a bastion connection or a direct connection to the machine (only possible with an external IP) is used, gardenadm needs to determine how to connect to the machine (i.e., the SSH target host).
Typically, a client (e.g., gardenctl ssh) would consult the Node.status.addresses field for this (ref).
However, there is no target cluster in gardenadm bootstrap – so no Node object.
By reporting Machine.status.addresses based on the infrastructure API, similar to what is reported in Node.status.addresses, MCM can support the gardenadm bootstrap use case.