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] (https://metallb.universe.tf/), 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 https://raw.githubusercontent.com/google/metallb/v0.7.3/manifests/metallb.yaml
This creates a namespace,
metallb-system, a bunch of other resources and
Next step, is to deploy a ConfigMap containing your configuration, see example below:
apiVersion: v1 kind: ConfigMap metadata: namespace: metallb-system name: config data: config: | address-pools: - name: defaul-ip-pool protocol: layer2 addresses: - 192.168.1.240-192.168.1.250
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
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.