RKE2 High Availability Explained
Вставка
- Опубліковано 29 вер 2024
- Finally sat down to explain RKE2 High Availability.
Docs : docs.rke2.io/i...
How I deployed the cluster : github.com/cle...
Please consider subscribing and comment what you would like to see in the next video.
Thanks for watching!
clemenko @ gmail . com
Can MetlaLB be used as external LoadBalancer for RKE2. And in the diagram, why would worker will exposed over DNS LB, It should be accessed from external LB over the control plane node.
MetalLB can be used in place of an ELB or DNS. Kube-vip could also be used. DNS records is a dead simple way to make it on the small scale. There are a few examples on youtube that show how to deploy both. How would you solve this problem?
Don’t rke2 has built in load balancer? When it connects to any master node it will receive list of other master nodes, so once 1 node goes down it automatically removes from load balancer list.
RKE2 can talk to the cloud providers to ask for a load balancer. RKE2 includes an ingress controller that can ask like an LB for applications. Let me know if this doesn't help.
Hi Andy, thank you for the yet another awesome RKE video.
Is there any Web-UI way (like via Harvester) to build that *High Availability* RKE2 cluster (3 masters & 3 workers)?
Thanks.
You can use Rancher on a core cluster to build out other clusters. Here is a video about it : ua-cam.com/video/L7TSawtl97w/v-deo.html
Thanks Andy for the great video. Appreciate it just like other videos. But I have a question. In this case the server -1 in the control plane, what if it goes down, how will server-2 and server-3 be promoted to being the next "master", it has to be done manually as far as I can see. How is this problem being solved?
I experimented a little bit on this and turned off server-1, it appears that server-2 is no longer automatically promoted to master which means the rules for HA fail. thoughts?
When setting up HA all 3 of the control plane nodes should be running rke-server. When you shut down server 1 it takes a minute or two for another node to be promoted. Behind the scenes etcds is the database that stores the cluster state. So server 2 and 3 still have the complete database of what is going. Also the workers can still talk to the control plane through either multiple DNS records or a load balancer. hope this helps.
@@clemenko Thanks for the response. We just did that however in the /etc/rancher/rke2/config.yaml the server-2 and server-3 technically point to server-1
Would that actually matter in this case?
We waited a good 5 minutes and did not see the server-2 or server-3 get promoted to master hence were wondering what would happen in a production grade scenario. Still experimenting!
We will keep you posted, appreciated your response.
That should word. Here is how I set up server 2 and 3 : github.com/clemenko/rke2/blob/main/deprecated_harv.sh#L115 . Make sure you have the same config with the addition of the "server:" and "token:" fields. Check the error logs with `journalctl -xefu rke2-server`.
@@clemenko Thanks so much for helping out. I figured you were right. I guess etcd automatically identifies a control plane server and ignore the "server" attribute which is used in server-3, which I thought was connecting to server-1. Technically it connects to etcd and so when server-1 is down, etcd automatically elects the other one as master.
Coincidentally it took quite a few minutes for that to get elected. Not sure why that may be the case. Thanks again for the great video and the assistance.
Behind the scenes etcd does the election. You pin the "server" field in the config to the first server for the all the `rke2-server`s. Then the workers use a load balancer to the 3 control plane nodes.
Glad to help. Let me know if you run into any other issues!