-
There are articles talking about the embedded etcd HA solution of k3s like this. One of the key behavior is adding a load balancer solution (EIP like this article or LB from the clound provider) between the agents and masters:
And the architecture of k3s also show that a Fixed Registration Address is necessary. While, after some research I found that k3s (at least v1.21.5+k3s2) have a internal agent load balancer (config at And I also do a experiment like this:
This behavior is so cool but I don't see any docs in k3s talking about this. So...do I misunderstand this behavior or there is little information about this behavior so that people still using a lb between agent and master? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
Our documentation lists a requirement for a "fixed registration endpoint" so that nodes do not rely on a single server being online in order to join the cluster. This endpoint could be a load-balancer or a DNS alias, it's up to you. This is only needed when nodes are registering to the cluster; once they have successfully joined, they use the client load-balancer to communicate directly with the servers without going through the registration endpoint. |
Beta Was this translation helpful? Give feedback.
Our documentation lists a requirement for a "fixed registration endpoint" so that nodes do not rely on a single server being online in order to join the cluster. This endpoint could be a load-balancer or a DNS alias, it's up to you. This is only needed when nodes are registering to the cluster; once they have successfully joined, they use the client load-balancer to communicate directly with the servers without going through the registration endpoint.