LoadBalancer Service on bare-metal Kubernetes clusters via MetalLB

Although bare-metal installations of Kubernetes can support both L4 and L7 load-balancing in theory, it does not provide any L4 load-balancing component to support type: LoadBalancerService types and expects the administrator to bring their own desired implementation. Therefore, I wanted to have this post dedicated to L4 load-balancing and how to provide it via MetalLB, but just for the sake of preserving the integrity of the topic, I want to give you a quick recap of service types in Kubernetes.

How to expose your services on your bare-metal Kubernetes; A quick guide

Kubernetes on public clouds are easy 😄. I don’t wanna be mean or anything but there are some things that we take for granted in public clouds when we run Kubernetes, such as the LoadBalancer service type. In a nutshell, we expose things running in Kubernetes via Services and a service definition in Kubernetes is as simple as this YAML file;

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: LoadBalancer # this is important!
  selector:
    app: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

and this will give us an IP address from our cloud provider, which we can directly hit and access our service, a website maybe. Pretty cool, isn’t it? This is particularly useful when you need to make services available beyond HTTP/HTTPS, potentially for applications relying on TCP/UDP protocols like databases, making them versatile for various types of applications.

But the bad news is, we don’t have this on bare-metal Kubernetes clusters 😄. At least, not by default. So there are some things that we need to consider if we want to expose our services, especially if we are running our services in a bare-metal Kubernetes cluster.