feat: add support for adding Robot/Dedicated servers

[pat-s]

@M4t7e Here's a first take on adding Robot support.

Two modes are offered:

1. Automated: Installs Talos through the rescue system and treats the full server as a Talos node
2. Manual: Creates a token which can be used in combination with kubeadm to join a non-Talos node to the cluster.

The README explains all of this in more detail.
I think the manual mode is important as often enough dedicated servers are used in shared approach, i.e. not all of their resources is used explicitly in a single cluster. For example, I am also currently running one dedi on Alma10 which joins another k3s cluster.

Please let me know what you think about this approach, so I know if its worth continuing!

[M4t7e]

Hey @pat-s, thanks for your initiative! 😊

If we integrated support for bare metal (robot) servers into this module, we would need to make it a first-class citizen. This would require me to maintain it properly in the future, test upgrades, handle configuration changes, and make sure everything continues to work before each new release. The configuration for these servers would also differ from the cloud-based ones. At the moment, I do not have a use case for bare metal nodes myself, so unfortunately I cannot maintain this right now.

I am aware that there is growing interest in this feature from other users as well (see: #61). Since we have just added sponsoring options for the project, I can offer to set this feature as a funding goal directly in the README. This way, monthly sponsorship income could finance a bare metal server. In theory, this should be easy to achieve, but it is no secret that open source projects often lack proper support and funding. Still, we can at least give it a try.

Regarding your second point, I do not see a strong need to implement this directly into the module. This could also be done with kubeadm instead. I would prefer to keep the module as clean and maintainable as possible. Every unnecessary feature increases the support, testing, and maintenance effort.

[pat-s]

Thanks for your response!

I think support for Robot servers is essential, to me and many others. It's also what makes running a cluster on Hetzner attractive for many in the first place.

This would require me to maintain it properly in the future, test upgrades, handle configuration changes, and make sure everything continues to work before each new release. The configuration for these servers would also differ from the cloud-based ones. At the moment, I do not have a use case for bare metal nodes myself, so unfortunately I cannot maintain this right now.

That's understandable. However, there are several possible approaches to this:

• Mark is as "community maintained" or "beta" to indicate it's different in testing/quality from the other parts of the modules
• Assign codeowners for these parts that take on the review/responsibility if you can't (because you don't have/need a Robot server)

There will still be issues/PRs/Discussions be opened, especially if it's not working well. Hence I understand that you might not want to have this. OTOH, this would then likely increase the risk of forks which will then cause users to be torn apart between projects. I think this should be avoided, for both sides :)

Since we have just added sponsoring options for the project, I can offer to set this feature as a funding goal directly in the README. This way, monthly sponsorship income could finance a bare metal server. In theory, this should be easy to achieve, but it is no secret that open source projects often lack proper support and funding. Still, we can at least give it a try.

If this is a blocker, I am also happy to sponsor it entirely to support the development of this feature for this project. Ideally, the costs are distributed among many which would like to see this feature but it is important enough to me that I don't want to wait several months until we reach an amount of 30-40 per month (auction server) to kick this off.
I'd like to migrate away from terraform-hetzner-kubernetes, for which I also mainly contributed the existing Robot integration.

Regarding your second point, I do not see a strong need to implement this directly into the module. This could also be done with kubeadm instead. I would prefer to keep the module as clean and maintainable as possible. Every unnecessary feature increases the support, testing, and maintenance effort.

Sure, however, it would be neat to just have to provide private network and vSwitch IDs to the module and have the module do all necessary tweaks to recognize the server.
In my end, such modules exist to exactly simplify such tasks to some degree and it would be a neat "middle way", but I can also understand if you don't want to have this and instead rather prefer a (long) guide how to achieve this externally.

I opened this PR to showcase a possible path and get some answers, so I know which way I need to take to migrate my existing hybrid cluster to this module.