MetalLB hooks into your Kubernetes cluster, and provides a network load-balancer implementation. In short, it allows you to create Kubernetes services of type “LoadBalancer” in clusters that don’t run on a cloud provider, and thus cannot simply hook into paid products to provide load-balancers.
kubectl apply -f https://raw.githubusercontent.com/google/metallb/v0.7.3/manifests/metallb.yaml
This will deploy MetalLB to your cluster, under the metallb-system namespace. The components in the manifest are:
-
The
metallb-system/controller
deployment. This is the cluster-wide controller that handles IP address assignments. -
The
metallb-system/speaker
daemonset. This is the component that speaks the protocol(s) of your choice to make the services reachable. -
Service accounts for the controller and speaker, along with the RBAC permissions that the components need to function.
-
Verify
kubectl get pods -n metallb-system -o wide
- Output
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
controller-765899887-g9pl7 1/1 Running 0 36s 10.10.3.2 worker-03 <none>
speaker-78znz 1/1 Running 0 36s 192.168.78.213 worker-03 <none>
speaker-kvb4q 1/1 Running 0 36s 192.168.78.211 worker-01 <none>
speaker-mmlzl 1/1 Running 0 36s 192.168.78.212 worker-02 <none>
The installation manifest does not include a configuration file. MetalLB’s components will still start, but will remain idle until you define and deploy a configmap.
Layer 2 mode is the simplest to configure: in many cases, you don’t need any protocol-specific configuration, only IP addresses.
For example, the following configuration gives MetalLB control over IPs from 192.168.78.50
to 192.168.78.150
, and configures Layer 2 mode:
Lets create a configmap yaml
vi metallb-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
namespace: metallb-system
name: config
data:
config: |
address-pools:
- name: default
protocol: layer2
addresses:
- 192.168.78.50-192.168.78.150
Create config map
kubectl create -f metallb-config.yaml
Part 14 - Test LoadBalancer