Question About create_load_balancer_for_the_kubernetes_api in HA Setup

[ZiedChekir]

Hello 👋,

First of all, thank you for this amazing tool. We’ve been using Hetzner K3s in production for two SaaS applications, and it has been working great.

I have a question about the create_load_balancer_for_the_kubernetes_api option. Why is it needed, and can we go without it in a high-availability setup?

From my understanding, worker nodes use the internal network to communicate with the master nodes, so an external load balancer shouldn’t be necessary for that. However, for external operations such as running kubectl commands or triggering CI/CD deployments we need to access the cluster externally.
In that case, do we need a dedicated load balancer specifically for the master nodes? Or can we use the same load balancer we use for our applications, even though it also routes traffic to the worker nodes?

So, just to confirm: in a highly available setup, is it required to have a dedicated load balancer for the master nodes in addition to the one used for the application? and since the LB has a location, where should it be placed in an HA setup across two different locations (both in Germany)?

Thank you in advance for the clarification.

[vitobotta]

Hi, you don't need to use the load balancer - in fact, at work, our clusters run without it. The load balancer is handy because it lets you use just one kube context and sends API requests to a different master at each request automatically. But right now, Hetzner load balancers don't work with their cloud firewalls. That means even if you set up hetzner-k3s to allow only certain IPs to reach the masters, the load balancer skips those rules and leaves the API open to the internet. Some people are okay with that, but it really depends on how sensitive your cluster is and what you're using it for.

If you turn off the load balancer, it's easy to switch between masters using tools like kubctx or just kubectl. The hetzner-k3s setup already creates a separate context for each master in your kubeconfig, so switching is simple. It's not quite as smooth as having the load balancer handle everything behind the scenes, but it works well and doesn't take much effort.

At work, we use a small bash function that picks a working master at random each time we connect - nothing fancy, just gets the job done.

One more thing - the load balancer only works if all your masters are in the same network zone.

[ZiedChekir]

Okay this is great Thank you :)