Kubernetes implementation in the cloud services like Amazon (EKS), Google (GKE) or Azure (AKS) provides out of the box capabilities like Multi-Master High Availability, Ingress Load Balancer (to handle in the traffic from the internet), Network Storage, and launching worker nodes with different hardware requirements.

All these facilities will NOT available if you install Kubernetes Clusters On-Premise if the infrastructure team uses an IaaS (Infrastructure as a Service) and builds the Kubnernetes cluster on bare metal.

This section will focus on how to deploy an Ingress enabled Load Balancer (at the Gateway) to handing the incoming traffic to the cluster.

Bare metal cluster operators have left with two lesser tools to bring user traffic into their clusters, “NodePort” and “externalIPs” services. Both of these options have significant downsides for production use, which makes bare metal clusters second class citizens in the Kubernetes ecosystem. (From metallb web site).

MetalLB is a load-balancer implementation for bare metal Kubernetes clusters, using standard routing protocols.

THe following section focuses Metal LB with Nginx Ingress Controller. If you want Metal LB with Istio (with Istio Ingress Controller) then click here > Istio Service Mesh. The recommended option is Metal LB with Istio.

Under Nginx, we have a simple hello world example while under Istio we have a much more powerful example to demonstrate.

1. A Kubernetes cluster, running Kubernetes 1.13.0 or later, that does not already have network load-balancing functionality.

2. A cluster network configuration that can coexist with MetalLB.

3. IPv4 addresses for MetalLB .

4. Depending on the operating mode, you may need one or more routers capable of speaking BGP.

A Kubernetes cluster: v1.15.1 (3 node cluster) is already set ready.

cluster network configuration : cilium

$ kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.5/examples/kubernetes/1.14/cilium.yaml

$ kubectl apply -f https://raw.githubusercontent.com/google/metallb/v0.8.1/manifests/metallb.yaml

(Reference https://metallb.universe.tf/installation/)

This will deploy MetalLB to your cluster, under the metallb-system namespace.

1. The metallb-system/controller deployment. (This is the cluster-wide controller that handles IP address assignments.)

2. The metallb-system/speaker daemonset. (This is the component that speaks the protocol(s) of your choice to make the services reachable)

3. Service accounts for the controller and speaker, along with the RBAC permissions that the components need to function.

MetalLB’s components will remain idle until you define and deploy a configmap.(for demo we will be using layer2 configuration)

$ kubectl apply -f  https://raw.githubusercontent.com/meta-magic/metallb-baremetal-example/master/metallb_install/configMap_example.yml

$ kubectl create -f https://raw.githubusercontent.com/meta-magic/metallb-baremetal-example/master/nginx-ingress/nginx_controller_install.yml

$ kubectl create -f https://raw.githubusercontent.com/meta-magic/metallb-baremetal-example/master/nginx-ingress/nginx_ingress_svc.yml

1. Create a namespace helloworld

$ kubectl create -f https://raw.githubusercontent.com/meta-magic/metallb-baremetal-example/master/helloworld_example/hello-world-ns.yml

2. Create a Pod (In production always use Deployment)

$ kubectl create -f https://raw.githubusercontent.com/meta-magic/metallb-baremetal-example/master/helloworld_example/hello-pod.yml

3. Create Service (with default cluster IP)

$ kubectl create -f https://raw.githubusercontent.com/meta-magic/metallb-baremetal-example/master/helloworld_example/hello-svc.yml

4. Expose the Service by creating an Ingress

$ kubectl create -f https://raw.githubusercontent.com/meta-magic/metallb-baremetal-example/master/helloworld_example/hello-ing.yml

$ kubectl get ing -n helloworld

Licensed under the Apache 2.0 License. [ by CC By 4.0

Enjoy!