MetalLB Load Balancer for K8sJanuary 24, 2022 | Cluster
Basically you would usually don't have to concern your self to much about this subject, when using the established cloud providers, as they usually have their own Load Blancer on the 2/3 OSI level. And networking in a K8s cluster is allready difficult for most people to get compfortably with. But, not to get confused with the higher level (7) ingress routing, usually done with Traefik, Nginx etc. you can probably view L2 Load Balancing as more of an egress issue in contrast to the load balancing often refered to when viewing documentation on ex. Traefik or Niginx.
So, why even consider this subject? The main reason is that you need a load balancer when running K8s in cluster formation and if you have a cluster setup on-prim or on different cheap VPS machines, the chances are that you need to configure one by your self. Often it will be clear for you if your deplyments will be "pending" for an external IP address.
You can follow the development of MetalLB at Github: https://github.com/metallb/metallb/tree/main/manifests
First we will be creating the namespace for MetalLB:
(kubectl apply -f namespace.yml)
Secrets are K8s way of distributing secret information between pods in a namespace (to prevent hardcoding these in the pods). You may consider using "encryption at rest" as this information is not encrypted by default. Setting up som RBAC rule to limit access to the "namespace", is also a very good idea.
Create a secret-key that is used by the speaker to communicate:
kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)"
Then navigate to the "metallb.yaml" file in the manifest directory, at MetalLB's Github repo (manifests/metallb.yaml), and copy the raw URL and apply the deployment file.
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/main/manifests/metallb.yaml
(now changed to)
The latest change in the above manifest (metallb-native.yaml), will automatically setup namespace and secret. So, you might skip those steps or delete existing ressources.
There are two options for configuring MetalLB, as BGP (I guess, is the ideal solution, if have machines in different locations, that have to work as one big cluster) or L2 which will be used here. Mainly because it seems like the easy path to go, but I might try to go for BGP at a later stage.
So, the simple L2 configuration would look something like this:
- name: my-ip-space
or for lets say a pool of public addresses (latest changes from metallb's docs)
The important point here is that you put in you IP address or IP address range, that should be reserved for the load balancer. After this you should be able to see external IP for your nodes.
Then they should be advertised:
# Setting no specific pool, uses them all
Disable Klipper on k3s
If you have already spun up a k3s cluster, you would like to disable servicelb (Klipper), if you want another loadbalancer.
It is important to disable it on all nodes (cp).
There should be other ways to carry out configuration changes, but this seems to be effective.
sudo vi /etc/systemd/system/k3s.service
and change the following line (this can for instance also be done with traefik):
server --disable servicelb \
and restart the service:
sudo systemctl daemon-reload && sudo systemctl restart k3s
If you have not yet initiated k3s:
So, to begin with we will include the following to our /etc/rancher/k3s/config.yaml on all CP nodes.