Using MetalLB to implement a network load balancer on Self-Hosted or Metal Kubernetes Installation

Have you been in situations where you create a load balancer and the External IP remains in a pending state? This is because Kubernetes does not offer implementations for network load balancers, it depends on IaaS platforms like GCP, Digital Ocean, AWS, Azure and others to provision a loadbalancer when required. This leaves self-hosted/bare metal Kubernetes clusters with either NodePorts or ExternalIPs services.

[MetalLB] (, a project by a Google Engineer, allows you to integrate a network load balancer that integrates with standard network equipment. All you need are IP addresses and a cluster network configuration that supports MetalLB, currently, Flannel, Romana and Weave Net fully are full supported.

After, setting up your cluster and installing a network add-on, all you need to do to setup MetalLB is to apply the MetalLB manifest:

kubectl apply -f

This creates a namespace, metallb-system, a bunch of other resources and controller & speaker DaemonSets.

Next step, is to deploy a ConfigMap containing your configuration, see example below:

apiVersion: v1
kind: ConfigMap
  namespace: metallb-system
  name: config
  config: |
    - name: defaul-ip-pool
      protocol: layer2

This configures MetalLB to deploy load balancers with IPs specified in the address-pool specified. The address pool can be a range of IP addresses or a subnet available based on your network environment.

With GitLab, this is useful if you are integrating GitLab with a bare metal Kubernetes cluster, and you keep getting ? for Ingress IP address while your Ingress service external IP remains at pending state.

To learn more about MetalLB, please see the review the concept notes and GitHub repo.

Do you have any quesion? Have you tried this? Did you experience any issues while trying to use MetalLB with GitLab or you have a different approach? Please share your comments below.

1 Like