Difficulty: Beginner
Estimated Time: 10 minutes

Source : https://metallb.universe.tf/tutorial/minikube/

In this scenarios, we'll set up some BGP routers, configure MetalLB to use them, and create some load-balanced services. We'll be able to inspect the state of the BGP routers, and see that they reflect the intent that we expressed in Kubernetes.

Because this will be a simulated environment inside Katacoda, this setup only lets you inspect the routers's state and see what it would do in a real deployment. Once you've experimented in this setting and are ready to set up MetalLB on a real cluster, refer to the installation guide for instructions.

Here is the outline of what we're going to do:

  1. Set up a Kubernetes cluster with Katacoda,
  2. Set up test BGP routers that we can inspect in subsequent steps,
  3. Install MetalLB on the cluster,
  4. Configure MetalLB to peer with our test BGP routers, and give it some IP addresses to manage,
  5. Create a load-balanced service, and observe how MetalLB sets it up,
  6. Change MetalLB's configuration, and fix a bad configuration,
  7. Tear down the playground.

Don’t stop now! The next scenario will only take about 10 minutes to complete.

MetalLB Demo

Step 1 of 5

Step 1

Set up a BGP routers

MetalLB exposes load-balanced services using the BGP routing protocol, so we need a BGP router to talk to. In a production cluster, this would be set up as a dedicated hardware router (e.g. an Ubiquiti EdgeRouter), or a soft router using open-source software (e.g. a Linux machine running the BIRD routing suite).

For this tutorial, we'll deploy a pod inside the cluster that runs both the BIRD and Quagga. They will be configured to speak BGP, but won't configure Linux to forward traffic based on the data they receive. Instead, we'll just inspect that data to see what a real router would do.

Deploy these test routers with kubectl: kubectl apply -f https://raw.githubusercontent.com/google/metallb/master/manifests/test-bgp-router.yaml

This will create a deployment for our BGP routers, as well as four cluster-internal services.

Wait for the router pod to start, by running the next command until you see the test-bgp-router pod in the Running state. kubectl get pods -n metallb-system

In addition to the router pod, the test-bgp-router.yaml manifest created four cluster-internal services:

  • The test-bgp-router-bird service exposes the BIRD BGP router at 10.96.0.100, so that we have a stable IP address for MetalLB to talk to.
  • Similarly, the test-bgp-router-quagga service exposes the Quagga router at 10.96.0.101.
  • Finally, the test-bgp-router-ui service is a little UI that shows us what routers are thinking.

Get Services : kubectl -n metallb-system get svc

Get the value of the Node port assigned : echo $(kubectl -n metallb-system get services/test-bgp-router-ui -o go-template='{{(index .spec.ports 0).nodePort}}')

Open Katacoda Web Preview and enter this port : http://[[HOST_SUBDOMAIN]]-[[KATACODA_HOST]].environments.katacoda.com/

If you're comfortable with BGP and networking, the raw router status may be interesting. If you're not, don't worry, the important part is above: our routers are running, but know nothing about our Kubernetes cluster, because MetalLB is not connected.

Obviously, MetalLB isn't connected to our routers, it's not installed yet! Let's address that. Keep the test-bgp-router-ui tab open, we'll come back to it shortly.