cluster-api-provider-hetzner VS microk8s

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.

If you want hands-on practice you should have a running Kubernetes cluster (I used MicroK8s for this tutorial) and Helm (see how to install on Installing Helm tutorial). It is important that you understand the basics of these tools to fully understand.

And install microk8s:

MicroK8s is a lightweight, batteries included Kubernetes distribution by Canonical designed for running edge workloads which also happens to be developer-friendly and a great choice for building your own homelab. The following lab covers how to install and run MicroK8s on your own edge node running Ubuntu 22.04 LTS, deploy the NGINX web service and exposing your NGINX website to the Internet with SSL/TLS enabled using AWS resources included within the Free Tier.

One quick and easy win I can recommend, is microk8s.

I had the same problem (and there's a github issue about this: https://github.com/canonical/microk8s/issues/2186). I swapped to k3s and the usage was half of what microk8s used.

microk8s currently has a showstopping issue that makes it guaranteed to have an irrecoverable failure in HA mode. see https://github.com/canonical/microk8s/issues/3227

k0s is better but also has a lot of bugs. it's the closest to vanilla kubernetes among all the distributions.

> like the simplest GPU support

linux users should be ready to install the nvidia device plugin. if they can't do that, they're never going to succeed in running a gpu accelerated application on their cluster anyway.

> like bootstrapping

in my experience, writing all the bootstrap scripts is painful. but now that there's chatgpt, so much of the drudgery as gone away.

MicroK8S to spin up a Kubernetes cluster

They now power my microk8s/x86 cluster (in addition to my 8-node Raspberry Pi4 ARM64 microk8s cluster), microceph cluster and my LXD cluster, and all are configured with WOL, so I can bring up the cluster from any machine in the homelab, on demand.