I've been diving into Kubernetes and set up a K3s cluster for my home lab, featuring one master node and three worker nodes. My networking is managed by MetalLB in L2 mode, using a single IP for cluster access, and I've configured Flannel with a wireguard-native backend. After performing maintenance on one of the worker nodes, I've run into a troubling problem. When I shut down and drain `worker03` and then restart it, all external connectivity via the MetalLB IP ceases. Although `worker01` is elected as the new leader during `worker03`'s downtime, the logs suggest that `worker03` still thinks it's the leader, causing a split-brain scenario. This perplexing issue leaves me with a functioning cluster until `worker03` powers back up. I'm puzzled as to why this split-brain behavior occurs post-reboot and whether it might relate to interactions between MetalLB L2 and the wireguard-native Flannel setup. Has anyone experienced similar issues? Any insights would be greatly appreciated!
1 Answer
I've been using MetalLB in various production environments for years without issues. It’s usually a reliable solution, so I can understand your frustration. You might want to check your configuration and logs to see if there's anything unusual. The simplicity of MetalLB can be both a blessing and a curse when troubleshooting.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures