about failover create_load_balancer_for_the_kubernetes_api

[louishot]

Hello,

I am a newbie and am testing and verifying the Kubernetes solution on hetzner.
We have a cluster of 3 masters and 4 worker
If I don't enable create_load_balancer_for_the_kubernetes_api, how can Worker nodes connect to the Master node? is it connect 1 of 3 master permanently? if that master is down how to failover?

Thank you

[vitobotta]

Hi, it's usually best to ask general questions in the discussions section. I like to keep the issue tracker for real problems that users have with the tool :) So I'm changing this to a discussion.

About your question: once the masters are connected to each other in the control plane and the cluster is operational, the worker nodes will connect to the control planel using the internal network inside the cluster. They don't connect through the external load balancer. Instead, they use the default kubernetes service that is created inside the cluster. This service handles the round robin load balancing between the masters.

[louishot]

Thanks for your quick reply.

I thought all workers connect to 127.0.0.1:6444 and the k3s-agent forwards to the right master.
I checked the k3s-agent config — why does it stay connected to just one master?
that 10.0.0.2:6443 is my master2

cat /var/lib/rancher/k3s/agent/kubelet.kubeconfig
apiVersion: v1
clusters:
- cluster:
    server: https://127.0.0.1:6444
    certificate-authority: /var/lib/rancher/k3s/agent/server-ca.crt
  name: local

cat /etc/systemd/system/k3s-agent.service.env
K3S_TOKEN='48ef87a1d8c94bc897496af7187cd451'
K3S_URL='https://10.0.0.2:6443'

[sk-rebricker]

@vitobotta I also stumbled upon the K3S_URL='https://10.0.0.2:6443' setting.

It seems like if a worker node is started after the master at 10.0.0.2 has gone down, it won't be able to join the cluster — even though a running node handles leader election internally.

Wouldn't it make sense to use the load balancer's internal IP for K3S_URL when a load balancer is configured? That way, worker nodes would always have a stable endpoint to connect to, regardless of which master is currently active.