Adding a load-balancer to our raspberry pi cluster

This part covers adding a load-balancer to our raspberrypi4 cluster.

The Plan

• Part 1: Setup a 3 node k3s cluster with 2 Master and 1 worker nodes (more worker nodes can be added later on)
• Part 2: Deploy metallb (load-balancer) to get traffic routed to the cluster.
• Part 3: Deploy traefik as a ingress controller to reach services by dns name
• Part 4: Deploy cert-manager for automatic creation of let’s encrypt certificates
• Part 5: Deploy longhorn for persistent-storage. (An alternative is using an NFS-Server as described here)
• Part 6: Cluster backup with velero.
• Part 7: Logging with loki
• Part 8: Use flux-cd for storing cluster description in git for rebuilding the cluster

The problem

When you want to use kubernetes in your home environment, you’ll have the problem of having one public-ip and three raspberrypi nodes which form the kubernetes cluster. How can you access your cluster from the outside?

The solution

The solution is to use an service which is called load-balancer which acts as single access-point to your cluster and automaticly balance traffic between the three nodes.

The implementation

One possible solution in the kubernetes ecosystem is using metallb.

Install metallb

kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.11.0/manifests/namespace.yaml
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.11.0/manifests/metallb.yaml

Source

Configuration

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: default
      protocol: layer2
      addresses:
      - 192.168.2.20-192.168.2.39 # IP-Range

This yaml-file of type ConfigMap tells metallb how to work. The important part is the IP-Range, which should match your routers IP-Range outside of the DHCP.

This prevents your router assigning metallb ips to your home-network devices.

So if your routers DHCP-Range is 192.168.2.1–192.168.2.100 you can use 192.168.2.101–192.168.2.103 as your metallb range.

Apply configuration

kubectl apply -f address-pool.yaml

Check if services are up and running with:

kubectl get pods -n metallb-system -o wide

If everything works fine it will like this:

NAME                                  READY   STATUS    RESTARTS      AGE   IP              NODE    NOMINATED NODE   READINESS GATES
metallb-controller-5488f4c94b-9k7kt   1/1     Running   1 (10d ago)   40d   10.42.1.73      kube2   <none>           <none>
metallb-speaker-msdrl                 1/1     Running   1 (10d ago)   40d   192.168.2.1     kube1   <none>           <none>
metallb-speaker-wtbrf                 1/1     Running   1 (10d ago)   40d   192.168.2.2     kube2   <none>           <none>
metallb-speaker-xw6rx                 1/1     Running   2 (10d ago)   40d   192.168.2.3     kube3   <none>           <none>

Finished

What’s next

The load-balancer is not so useful alone but in the next part we install an ingress controller to route traffic to our services.