MetalLB 在 Kubernetes 中的工作原理答案

【问题标题】：How MetalLB works in KubernetesMetalLB 在 Kubernetes 中的工作原理
【发布时间】：2021-07-05 19:34:58
【问题描述】：

谁能解释一下 MetalLB 如何在 Kubernetes 环境中获取 IP 地址？我已经在 GCP 计算引擎中安装了 Kubernetes 集群。我在 MetalLB ConfigMap 中提供了一系列内部 IP 地址。

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

在我的情况下，我在 CM 中提供的 IP 范围是 10.140.0.30-10.140.0.40

它按预期工作，但我想知道 MetalLB 如何获取 IP 地址。

【问题讨论】：

作为metallb，不支持：metallb.universe.tf/installation/clouds 但通常情况下，当您配置正确后，您可以将Service暴露为“LoadBalancer”，然后它会从CM中获取IP。跨度>
其实我并没有在 GCP 中使用托管的 Kubernetes 服务。它由3个Master和3个Worker组成。它们是计算引擎
您是否尝试使用type: LoadBalancer 公开服务？
是的。它对我有用。我在问这背后的机制？
是的，它将处于“待定”状态。不会得到任何IP地址。我经历过这个。所以基本上在 ConfigMap 中提供 IP 范围意味着 Metal LB 会从云供应商那里租用这些 IP 地址，对吧？就我而言，来自 GCP

标签： kubernetes load-balancing metallb

【解决方案1】：

总结一下我的cmets：

第 2 层模式下的 MetalLB 在每个节点上部署一个 Speaker Pod，该 Pod 响应 ARP(IPv4) 和 NDP(IPv6) 请求。

如果您现在连接到 IP，您的 Kubernetes 服务使用 type: LoadBalancer 从您在 MetalLB 配置中定义的范围获得，您的客户端将向网络发送 arp-request who-has <IP-Service>, tell <IP-Client>。由于 Speaker Pod 正在侦听 arp-request，因此它们将使用 reply <IP-Service> is-at <node-MAC-address-of-the-leader> 进行回答。

这并不意味着您的 Pod 运行在解析了 Mac 地址的那个节点上，只有 MetalLB “领导者”在这个节点上运行。然后，您的请求将传递给知道您的 Pod 所在位置的 Kube-Proxy。

还要记住：

从这个意义上说，第 2 层没有实现负载平衡器。相反，它实现了一种故障转移机制，以便在当前领导节点由于某种原因发生故障时可以由不同的节点接管。

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

【讨论】：