2

Can anybody explain me how MetalLB gets IP addresses in a Kubernetes environment? I have installed Kubernetes cluster in GCP compute engines. I have provided a range of Internal IP addresses in MetalLB ConfigMap.

NAME        STATUS   INTERNAL-IP   EXTERNAL-IP     
instance-1  Ready    10.140.0.20   56.169.53.26    
instance-2  Ready    10.140.0.21   57.11.92.241   
instance-3  Ready    10.140.0.22   54.7.255.253

In my case the IP range which I gave in the CM was 10.140.0.30-10.140.0.40

It works as expected but I want to know how MetalLB get's IP addresses.

Dusty
  • 231
  • 1
  • 3
  • 16
  • As metallb, it's not supported: https://metallb.universe.tf/installation/clouds/ But normally, when you have configured it right, you can expose an Service as "LoadBalancer" and then it will grab an IP from the CM. – CLNRMN Jul 02 '21 at 11:37
  • Actually I'm not using the managed Kubernetes service in GCP. It consists of 3 Masters and 3 Workers. They are compute engines – Dusty Jul 02 '21 at 11:39
  • Did you try to expose a Service with `type: LoadBalancer` ? – CLNRMN Jul 02 '21 at 11:48
  • Yes. It worked for me. I'm asking about the mechanism behind this? – Dusty Jul 02 '21 at 11:56
  • If you run it in L2 mode, it answers to arp-requests in the network. So if i client would like to connect to that ip, it has to know where it is and i checks that within the arp table. Since metallb is answering to this request, the client sends it to the mac-address of the node which the metallb-speaker is listening. – CLNRMN Jul 02 '21 at 11:59
  • Oh I understand. So once it exceeded the given IP range (In my case 10 IP addresses) it should obviously give an error right? Since all the 10 IP's are already allocated? Correct me if I'm wrong. – Dusty Jul 02 '21 at 12:09
  • i don't know tbh, i think your Service will not receive any ip then. – CLNRMN Jul 02 '21 at 12:12
  • 1
    Yeah it will be in "Pending" state. Won't get any IP address. I've experienced this. So basically providing the IP range in the ConfigMap means Metal LB will lease those IP addresses from the cloud vendor right? In my case from GCP – Dusty Jul 02 '21 at 12:14
  • Yes, that's true. – CLNRMN Jul 02 '21 at 12:18
  • @CLNRMN as you were the person that answered the questions/concerns in the comments, could you please provide an answer to this question to give it to more visibility and to indicate that this question was resolved? – Dawid Kruk Jul 04 '21 at 21:38

1 Answers1

2

to summarize my comments:

MetalLB in layer 2 mode is deploying on each node a Speaker Pod which responds to ARP(IPv4) and NDP(IPv6) requests.

If you now connect to the IP, which your Kubernetes Service with type: LoadBalancer got from the range you have defined in the MetalLB configuraton, your client will send out an arp-request who-has <IP-Service>, tell <IP-Client> to the Network. Since the Speaker Pods are listening to arp-requests, they'll answer with reply <IP-Service> is-at <node-MAC-address-of-the-leader>.

It does not mean, that your Pod is running on that Node which the Mac-Address is resolved, only the MetalLB "leader" is running on this one. Your request will pass then over to the Kube-Proxy which is aware where your Pod lives.

Also keep in mind:

In that sense, layer 2 does not implement a load-balancer. Rather, it implements a failover mechanism so that a different node can take over should the current leader node fail for some reason.

https://metallb.universe.tf/concepts/layer2/#load-balancing-behavior

CLNRMN
  • 1,409
  • 9
  • 23