<p>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.</p>
<pre><code>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
</code></pre>
<p>In my case the IP range which I gave in the CM was 10.140.0.30-10.140.0.40</p>
<p>It works as expected but I want to know how MetalLB get's IP addresses.</p>

Dusty
<p>to summarize my comments:</p>
<p>MetalLB in layer 2 mode is deploying on each node a <em>Speaker</em> Pod which responds to ARP(IPv4) and NDP(IPv6) requests.</p>
<p>If you now connect to the IP, which your Kubernetes Service with <code>type: LoadBalancer</code> got from the range you have defined in the MetalLB configuraton, your client will send out an arp-request <code>who-has &lt;IP-Service&gt;, tell &lt;IP-Client&gt;</code> to the Network.
Since the <em>Speaker</em> Pods are listening to arp-requests, they'll answer with <code>reply &lt;IP-Service&gt; is-at &lt;node-MAC-address-of-the-leader&gt;</code>.</p>
<p>It does not mean, that your Pod is running on that Node which the Mac-Address is resolved, only the MetalLB &quot;leader&quot; is running on this one. Your request will pass then over to the Kube-Proxy which is aware where your Pod lives.</p>
<p>Also keep in mind:</p>
<blockquote>
<p>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.</p>
</blockquote>
<p><a href="https://metallb.universe.tf/concepts/layer2/#load-balancing-behavior" rel="nofollow noreferrer">https://metallb.universe.tf/concepts/layer2/#load-balancing-behavior</a></p>
