metalLB 云兼容性

bobz965
70 阅读9分钟

MetalLB 与云平台兼容性及替代方案

1. 一段话总结

总体而言，MetalLB主要适用于裸机集群，与大多数云服务提供商不兼容，仅对Equinix Metal、Hetzner、OVH等少数平台提供支持；其不兼容多数云平台的核心原因是云平台多采用专有API而非标准网络协议（如BGP、ARP），导致MetalLB无法正常发挥作用；对于不支持的云平台，可选择使用云平台自带的负载均衡器或keepalived-vip作为替代方案，同时部分支持平台需进行特定配置才能正常运行MetalLB。

image.png

3. 详细总结

一、MetalLB云平台兼容性整体情况

  1. 核心定位与兼容性基调：MetalLB 主要为裸机集群设计，与大多数云服务提供商不兼容；即便部分云厂商提供“专用服务器”，通常也不支持 MetalLB 所需的网络协议。

  2. 支持状态说明：文档提供的云平台列表并不完整，未被列出的平台，其支持状态未知，但大概率不支持；若明确知晓某未列出平台的支持情况，可通过提交 pull request 更新列表。

  3. 各云平台支持情况明细：

Cloud platform（云平台）Supported（支持情况）备注
AWSNo需使用 EKS
AzureNo需使用 AKS
DigitalOceanNo需使用 DigitalOcean Kubernetes
Equinix MetalYes需参考 Equinix Metal 专属说明
Google CloudNo需使用 GKE
HetznerYes需参考 Hetzner专 属说明
OVHYes仅在使用 vRack 时支持
OpenShift OCPYes需参考 OpenShift 专属说明，需特定配置
OpenStackYes需参考 OpenStack 专属说明，需特定配置
ProxmoxYes无额外备注，直接支持
VMwareYes无额外备注，直接支持
VultrYes无额外备注，直接支持

二、MetalLB不兼容多数云平台的原因

MetalLB通过标准路由协议实现负载均衡功能，但云平台对这些协议的支持方式无法满足其需求，具体原因如下：

  1. BGP 协议支持问题：

    1. 云平台中 BGP 支持较为少见，且现有支持通常仅用于接收来自云外位置的入站路由公告（如 Google Cloud Router）；
    2. 这导致 MetalLB 的 BGP 模式要么完全无法运行，要么无法实现多数用户所需功能，且效果远不如云平台自带的负载均衡产品。

  2. ARP协议功能问题：

    1. 云平台的虚拟网络层会模拟 ARP 功能，仅允许解析由云平台分配给虚拟机（VM）的 IP 地址；
    2. 而 MetalLB 的 L2 模式依赖正常以太网网络中的 ARP 行为，该模拟机制直接导致 L2 模式失效。

  3. 公网 IP 分配与路由问题：

    1. 即便部分场景下 ARP 可正常工作，云平台对公网 IP（常称“浮动IP”）的分配流程，与虚拟网络的集成方式并非标准化；
    2. 这使得 MetalLB 无法通过 ARP “获取”浮动 IP 并将其路由到正确位置，需通过云平台专有 API 重新路由 IP，而 MetalLB 不支持此类 API。

  4. 核心原因总结：云服务提供商通过专有API而非标准网络协议控制网络层，MetalLB无法与这些专有API适配，因此无法在多数云平台运行。

三、支持平台的特定配置要求

针对部分明确支持的平台，需进行特定配置才能使 MetalLB 正常运行：

  1. OpenShift OCP平台：

    1. 调整 Pod UID 相关配置：OpenShift 会基于管理的 UID 范围自动为 Pod 分配 UID，需从 MetalLB清单中移除硬编码的非特权 UID，具体为删除controller Deployment和speaker DaemonSet中spec.template.spec.securityContext.runAsUser字段；同时，因 OpenShift 允许的组 ID 范围为5000-5999，需一并删除上述两个资源中的spec.template.spec.securityContext.fsGroup字段。
    2. 授予网络相关高权限：需为speaker DaemonSet授予高级别网络权限，执行命令：oc adm policy add-scc-to-user privileged -n metallb-system -z speaker；若通过 Helm 部署 MetalLB，需注意ServiceAccount 名称为metallb-speaker。

  2. OpenStack平台：

    1. 若在 OpenStack 虚拟机上运行 Kubernetes 集群并使用 MetalLB 的 L2 模式，必须禁用所有运行 Kubernetes 的虚拟机的 ARP 欺骗保护（关闭端口安全）；
    2. 原因：MetalLB 的 L2 模式会向 OpenStack 宣告其未知的 IP 地址，从 OpenStack 视角看类似 ARP 欺骗行为，目前无其他协作方式，只能完全关闭欺骗保护。

  3. Equinix Metal平台：

    1. 该平台属于“类裸机”云平台，支持通过 BGP 协议宣告和路由浮动 IP 至服务器，因此 MetalLB 的 BGP模式可完美运行；

    2. 官方提供支持：Equinix Metal 团队编写了专属教程，指导如何通过 MetalLB 将 Kubernetes 负载均衡器与其 BGP 基础设施集成。

四、不支持平台的替代方案

若所用云平台不支持 MetalLB，可选择以下两种主要替代方案：

  1. 使用云平台自带的负载均衡器：

    1. 优势：通常功能更丰富、性能更高，且多数云厂商会维护与 Kubernetes 的集成模块，兼容性和稳定性更有保障。

  2. **使用 keepalived-vip **：

    1. 本质：基于 keepalived 的简单封装工具，部分用户已成功用于 Kubernetes 虚拟 IP 配置。

    2. 核心功能：支持故障转移事件发生时触发 shell 脚本钩子，可通过自定义脚本对接云平台专有 API，实现IP 路由调整。

    3. 注意事项：

      • 单独使用 keepalived-vip 无法正常工作，因其基于 VRRP 协议（与 MetalLB 的 L2 模式功能相近），若 MetalLB L2 模式失效，VRRP 同样会受影响；

      • 与 Kubernetes 集成度较低：无法直接支持 LoadBalancer Service 对象，通常需配合HTTP(S) ingress 控制器使用；

      • 文档资源较少：该方案使用范围较窄，可通过搜索 “keepalived-vip” 获取相关实施信息。

五、MetalLB支持更多云平台的可能性

  1. 理论可行性：从技术角度看，MetalLB 可通过适配云平台专有 API，实现与裸机集群中标准网络协议相同的功能，从而支持更多云平台。

  2. 当前限制：** MetalLB 缺乏资金用于购买云资源，以测试与各云平台的集成效果**；若云服务提供商或其他赞助商愿意提供测试所需资源（如服务器、IP 等），则有可能为 MetalLB 添加更多云平台的支持。

4. 关键问题

问题1：MetalLB 与多数云平台不兼容的核心技术原因是什么？这些原因分别如何影响 MetalLB 的运行？

答案：

核心技术原因是云服务提供商通过专有 API 而非标准网络协议控制网络层，具体影响体现在三个方面：

  1. BGP 协议支持不足：云平台中 BGP 支持较为少见，且现有支持多用于接收云外入站路由公告（如Google Cloud Router），无法满足 MetalLB BGP 模式的需求，导致该模式要么失效，要么功能不符合预期，且效果远差于云平台自带负载均衡器。

  2. ARP 协议模拟限制：云平台虚拟网络层会模拟 ARP 功能，仅允许解析其自身分配给虚拟机的 IP 地址，而 MetalLB 的 L2 模式依赖正常以太网中的 ARP 行为，该模拟机制直接导致 L2 模式无法识别和使用所需 IP，进而失效。

  3. 公网 IP 分配非标准化：云平台对公网IP（浮动IP）的分配与虚拟网络集成方式不标准，MetalLB 无法通过 ARP “获取”浮动 IP 并完成路由，需通过云平台专有 API 操作，而 MetalLB 不支持此类 API，导致 IP 路由无法实现。

问题2：在支持 MetalLB 的云平台中，OpenShift OCP 和 OpenStack 分别需要进行哪些关键配置？这些配置的目的是什么？

答案：

OpenShift OCP 的关键配置及目的

  1. 配置1：移除特定安全上下文字段

    1. 操作：删除controller Deployment和speaker DaemonSet中spec.template.spec.securityContext.runAsUser（硬编码非特权UID）和spec.template.spec.securityContext.fsGroup（组ID）字段。
    2. 目的：适配 OpenShift 的 UID 和组 ID 管理机制—— OpenShift 会自动为 Pod 分配 UID（基于其管理的 UID 范围），且允许的组 ID 范围为 5000-5999，移除硬编码字段可避免权限冲突，确保 Pod 正常启动。

  2. 配置2：授予 speaker DaemonSet 高权限

    1. 操作：执行命令oc adm policy add-scc-to-user privileged -n metallb-system -z speaker（Helm部署时ServiceAccount名为metallb-speaker）。

    2. 目的：speaker组件需执行原始网络操作以实现负载均衡功能，授予其privileged权限可满足该组件对网络控制的需求，确保 MetalLB 正常工作。

OpenStack的关键配置及目的

  1. 配置：禁用所有 Kubernetes 节点 VM 的 ARP 欺骗保护

    1. 操作：在 OpenStack 平台中，对所有运行 Kubernetes 的虚拟机，关闭其 ARP 欺骗保护功能（仅L2模式下需配置）。

    2. 目的：MetalLB 的 L2 模式会向 OpenStack 宣告其未知的 IP地 址，OpenStack 默认会将该行为识别为 ARP 欺骗并拦截，禁用保护后可允许 MetalLB 正常宣告 IP，确保 L2 模式生效。

问题3：若所用云平台不支持 MetalLB，有哪些替代方案？各方案的优势、局限性分别是什么？

答案：

共有两种主要替代方案，具体对比如下：

替代方案优势局限性
云平台自带负载均衡器1. 功能更丰富，支持更多云平台专属特性；
2. 性能更高，适配云平台底层架构；
3. 有云厂商官方维护的Kubernetes集成模块，兼容性和稳定性强		1. 与云平台绑定，迁移性差，更换云平台需重新适配；
2. 可能产生额外的服务费用，成本相对较高
keepalived-vip1. 可通过自定义shell脚本对接云平台专有API，实现虚拟IP配置；
2. 基于成熟的keepalived工具，核心VRRP协议稳定性有保障		1. 单独使用无法工作，需编写自定义脚本对接云API，技术门槛较高；
2. 与Kubernetes集成度低，不支持LoadBalancer Service对象，需配合HTTP(S) ingress控制器；
3. 使用范围窄，文档资源少，问题排查难度大

参考

  1. metallb.universe.tf/installatio…
avatar
文章
阅读
粉丝