EKS Anywhere., and MetalLB Load Balancer services

4 min readMay 9, 2022

This article is a part of the multi-part story of EKS Anywhere. Access it here EKS Anywhere, extending the Hybrid cloud momentum | by Ambar Hassani | Apr, 2022 | Medium

This article has been updated for v0.13.0+ due to depreciation of ConfigInLine method of creating IP address pools.

Kubernetes core and/or EKS Anywhere equally does not provide for any Load Balancers. Here in the choices are left to the end adopter of deploying a relevant load-balancer that can help access the spread of of deployed applications via the pods

Generally speaking., in public clouds, the default integrations with the load-balancer service extensions are an out-of-box solution. However, in an on-premises scenario, you would need a hardware or a software defined load-balancer that can be integrated with your Kubernetes cluster.

This could be a limiting factor both in terms of cost as well as availability and integration of such solutions from leading vendors.

In that context, the MetalLB open source project is one of the preferred choices for alternative Load balancer services that does not depend on any external load-balancers. While the project aimed at bare-metal clusters (hence the name)., however it can be used with any kind of cluster (bare-metal or virtualized).

MetalLB is one of the most popular on-premises replacements for the LoadBalancer cloud integrations. The whole solution runs inside a particular Kubernetes cluster where these services are needed. MetalLB is a native Kubernetes load balancing solution for bare-metal Kubernetes clusters. Detailed information about MetalLB can be found here

The main component is an in-cluster Kubernetes controller which watches LB service resources, and based on the configuration supplied in a ConfigMap, allocates and writes back IP addresses from a dedicated pool for new services. It maintains a leader node for each service, and depending on the working mode, advertises it via BGP or ARP (sending out unsolicited ARP packets in case of failovers).

The main difference from the user’s point of view between the two is that the ARP solution requires each node to be in a single L2 network (subnet), while BGP requires dynamic routing configuration on the upstream router.

Let’s apply this solution in the context of EKS Anywhere and practically view it’s benefit and usage.

Note: We will use the Layer 2 mode of MetalLB implementation for this scenario

Pre-requisite:

A working EKS Anywhere cluster either standalone or with a dedicated management cluster. It does not matter which model you use to deploy the cluster., at the end of the day we need a working EKS Anywhere cluster.

Note: As per the cluster creation process you should have ear-marked a set of static IP addresses (for control plane and for load balancer services). We will need those static IP addresses in this configuration

In my case the range of IP addresses used as static are 172.24.165.21 to 172.24.165.25 (yours could/will be different)

Step-1 Install MetalLB via the helm chart

Assuming our cluster name is testworkload01source eks-anywhere/cluster-ops/switch-cluster.sh
clusterName: testworkload01Once the above is done, the kubeconfig and context is set for the admin user targeting testworkload01 EKS Anywhere clusterhelm repo add metallb https://metallb.github.io/metallb
helm install metallb metallb/metallb --wait --timeout 15m --namespace metallb-system --create-namespace
Release "metallb" does not exist. Installing it now.
W0711 06:55:51.507363   23991 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
W0711 06:55:51.510195   23991 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
W0711 06:55:51.606228   23991 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
W0711 06:55:51.607914   23991 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
NAME: metallb
LAST DEPLOYED: Mon Jul 11 06:55:48 2022
NAMESPACE: metallb-system
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
MetalLB is now running in the cluster.Now you can configure it via its CRs. Please refer to the metallb official docs
on how to use the CRs.Next we will use the Custom Resources to create the IP address pools and advertise themcat <<EOF | kubectl apply -f -
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: first-pool
  namespace: metallb-system
spec:
  addresses:
  - 172.24.165.21-172.24.165.25
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: example
  namespace: metallb-system
EOFipaddresspool.metallb.io/first-pool created
l2advertisement.metallb.io/example created

Step-2 Deploy sample application and quick observations

Sample files for the load-balancer testing using a hello-world deployment are already placed inside of /home/ubuntu/eks-anywhere/hello-world sub-directory

kubectl apply -f hello-world-deployment.yamlOnce the pods are in running statekubectl apply -f hello-world-service.yaml

As one can see from the above output, the service name hello-world gets an IP address of 172.24.165.21. This is due to the fact that my static IP ranges 172.21.165.21 to 172.24.165.25

In addition, one can also see from the service description how the MetalLB controller interacts with the Kubernetes control plane to assign the IP address and update the hello-world service.

Step-4 Observe MetalLB constructs

We can use the below gist to issue commands and observe the namespace, pods created after installing MetalLB. You can notice that the above installation creates one controller as a Deployment type pod and another 4 pods via a DaemonSet.

All these run in a dedicated namespace called metallb-system

That’s it for now. Hope you found the article insightful and easy to get started with deploying MetalLB on EKS Anywhere clusters

cheers

Ambar@thecloudgarage

#iwork4dell