cluster-api-provider-hetzner VS kubernetes-the-hard-way

Hetzner Cloud is officially supported, but that means setting up VPSs in Hetzner's Cloud offering, whereas this project was intended as a more or less independent pure bare-metal cluster. I see they offer Bare Metal support as well, but I haven't dived too deep into it.

I haven't used KubeOne, but I have previously used Syself's https://github.com/syself/cluster-api-provider-hetzner which I believe works in a similar fashion. I think the approach is very interesting and plays right into the Kubernetes Operator playbook and its self-healing ambitions.

That being said, the complexity of the approach, probably in trying to span and resolve inconsistencies across such a wide landscape of providers, caused me quite a bit of grief. I eventually abandoned this approach after having some operator somewhere consistently attempt and fail to spin up a secondary control plane VPS against my wishes. After poring over loads of documentation and half a dozen CRDs in an attempt to resolve it, I threw in my hat.

Of course, Kubermatic is not Syself, and this was about a year ago, so it is entirely possible that both projects are absolutely superb solutions to the problem at this point.

For anyone interested in Kubernetes on Hetzner, there's a really interesting CAPI provider being actively developed:

https://github.com/syself/cluster-api-provider-hetzner

Just a hint running ML Workloads on Hetzner is pretty cheap! You could use for managing k8s: https://github.com/syself/cluster-api-provider-hetzner

we (Syself) release Cluster-API Provider Hetzner v1.0.0-beta.16.

ah okay they come from the upstream cluster-api project. The caph project implements only the infrastructure provider part of Cluster API.

you can easily use it with https://github.com/syself/cluster-api-provider-hetzner

I would use cluster-api-provider-hetzner from Syself.

As I delved into the world of Kubernetes, I opted for what seemed like the scenic route—until reality hit. With determination and a sprinkle of naivety, I plunged into crafting a Kubernetes cluster from scratch. Little did I know, I was in for a wild ride of commands, configurations, and complexities. But fear not! With the guiding light of a course based on the notorious "Kubernetes The Hard Way" GitHub repository, albeit customized for AWS instead of Google Cloud, I embarked on my journey to build my digital fortress, one step at a time.

Another resource that I found pretty helpful was "Kubernetes the Hard Way" by Kelsey Hightower despite its complexity.

https://github.com/kelseyhightower/kubernetes-the-hard-way

I recently published Kubernetes the Harder Way, a guide loosely based on Kelsey Hightower's Kubernetes the Hard Way, but lenghtier, more explanatory, broader in scope, and - most importantly - harder, by targeting a local machine instead of Google Cloud Platform.

How about this? It will setup a kubernetes cluster on GCP with 3 worker nodes?

https://github.com/kelseyhightower/kubernetes-the-hard-way

Some costs here but click on the google cloud calc as it seems to have gone up since he wrote this:

If you wanna go all in: https://github.com/kelseyhightower/kubernetes-the-hard-way

Oh, and both: "Kubernetes up and Running" and "Production Kubernetes" are great books.

Using Kubernetes The Hard Way is a great way to learn it deeply and quickly.

If you wanna learn it deeply and quickly, Kelsey Hightower's Kubernetes the hard way is fantastic!