Add ssh key check for autoscaler

[privatecoder]

Attempted goal

1. Set up a dev cluster with autoscaling nodes
2. Be able to ssh into autoscaled nodes

Issues

• Could not ssh into autoscaled nodes, because the ssh key was not added to authorized_keys on the node
• After investigating I found that yout tool sets HCLOUD_SSH_KEY in the cluster‑autoscaler deployment to
settings.cluster_name so the autoscaler injects that key when it creates nodes.
• As I added the key before under a slightly different name, this did not work

Solution

Added a check, so that if any worker pool has autoscaling.enabled: true and addons.cluster_autoscaler.enabled: true, it:

• Finds the SSH key by fingerprint or name.
• If the key found has a different name than cluster_name, it aborts with a clear error that autoscaler won’t work.
• If no key exists yet, it lets create proceed (hetzner‑k3s will create it).

If it fails, it prints:

[Configuration] - Cluster autoscaler requires an SSH key named 'dev' in Hetzner. A key with the same fingerprint exists as 'dev1', so hetzner-k3s will not create 'dev'. Autoscaled nodes will be created without SSH keys. Rename or delete the existing key, or change cluster_name.

[vitobotta]

This looks good. A couple of suggestions:

1. I'd place the validation in a separate validator class - other validators are in separate files (e.g., kubectl_presence.cr, helm_presence.cr). This could be autoscaler_ssh_key.cr for consistency.

2. The Hetzner API call adds latency to all creates and this validation runs even for clusters without autoscaling. An early returns when the autoscaling is not in use would (either the autoscaler is disabled or no node pools have autoscaling enabled).

WDYT?

[vitobotta]

Actually no worries, I'll do it now since I want to make a new release.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[vitobotta]

Merged. Thanks!