概述

在公有云部署的kubernetes集群中，有公有云廠商提供LoadBalancer類型的Service。但是在基于本地環境部署的k8s集群是我們常用的測試環境和開發環境；需要通過NodePort和externalIPs方式將外部流量引入集群中，這就帶來了很多的不便。

尤其是我們通過helm去部署一些服務時，嘗嘗會依賴于LoadBalancer的資源類型，導致創建的services中type: LoadBalancers會一直處于Pending狀態；我們不得不進行倉庫的fetch，然后手動進行values的修改。

Metallb 通過標準路由協議能解決該問題。MetalLB 也是 CNCF 的沙箱項目，最早發布在
https://github.com/google/metallb 開發，后來遷移到 https://github.com/metallb/metallb 中。

MetalLB 通過 MetalLB hooks 監聽SVC的變化；然后通過Speaker組件采用對應的模式將外部流量引流到kubernetes集群node節點的可達路徑。而具體到Pod中則是通過kuber-proxy依據轉發模式(iptables或ipvs)將流量轉發到Pod中。

MetaLB負責從主機維度實現負載均衡，而pod副本間的負載是通過kube-proxy實現。MetalLB負責IP地址分配、依據設定的廣播模式進行廣播、節點選舉、節點失效切換等功能。而引流的過程則通過ARP、NDP和BGP標準路由協議實現。

主要的兩大功能：

1. 地址分配：用戶需要在配置中提供一個地址池，Metallb 將會在其中選取地址分配給服務。
2. 地址廣播（IP外部聲明）：根據不同配置，Metallb 會以二層（ARP/NDP）或者 BGP 的方式進行地址的廣播。

工作模式：

1. BGP模式（Layer 3），使用BGP協議分配地址池；運行 BGP 的設備之間可以交換路由信息，我們可以將自己的 IP 段通過 BGP 協議告訴其他設備，這樣其他設備就能正確的路由數據包到服務器上了。BGP 需要路由器的支持。如果Calico也是使用的BGP模式，有可能會有沖突從而導致metallb無法正常工作。
2. ARP（IPV4）/NDP(IPV6)工作模式（Layer2）；使用 ARP/NDP 協議分配地址池；在服務器的內部子網里找未使用的 IP，然后等其他電腦訪問這個 IP 的時候，我們回應一個 ARP 包，其他電腦就知道這個 IP 在哪里可以通信了，盡管這個 IP 其實沒有綁定到任何網卡上，也有可能只是 iptables 里的一條記錄。分配的 IP 只能和服務器其他 IP 位于同一子網，這就要求我們所有的節點必須在同一個二層網絡內。

更多詳情請參考官方文檔：https://metallb.universe.tf/。

架構

二層部署的架構圖，參考紅帽openshift官方文檔。

上圖顯示了與 MetalLB 相關的以下概念：

• 應用程序可以通過在 172.130.0.0/16 子網上具有集群 IP 的服務獲取。該 IP 地址可以從集群內部訪問。服務也有一個外部 IP 地址，用于分配給服務的 MetalLB，即 192.168.100.200。
• 節點 1 和 3 具有應用程序的 pod。
• speaker 守護進程集在每個節點上運行一個 pod。MetalLB Operator 啟動這些 pod。
• 每個 speaker pod 都是主機網絡的 pod。容器集的 IP 地址與主機網絡上節點的 IP 地址相同。
• 節點 1 上的 speaker pod 使用 ARP 聲明服務的外部 IP 地址 192.168.100.200。聲明外部 IP 地址的 speaker pod 必須與服務的端點位于同一個節點上，端點必須為 Ready 條件。
• 客戶端流量路由到主機網絡，并連接到 192.168.100.200 IP 地址。在流量進入節點后，服務代理會根據您為服務設置的外部流量策略，將流量發送到同一節點上的應用 pod 或其他節點。
• 如果節點 1 不可用，則外部 IP 地址將故障轉移到另一節點。在具有應用 pod 和服務端點實例的另一個節點上，speaker Pod 開始宣布外部 IP 地址 192.168.100.200，新節點接收客戶端流量。在圖中，唯一的候選項是節點 3。

部署

環境要求

集群版本信息如下：

支持MetalLB的CNI如下：

注意事項：

• 參考 CLOUD COMPATIBILITY https://metallb.universe.tf/installation/clouds/ 查看你的環境是否支持 MetalLB
• 使用 BGP 工作模式時，需要一臺或多臺支持 BGP 的路由器
• 由于第 2 層模式依賴于 ARP 和 NDP，客戶端必須位于沒有中斷服務的節點所在的同一子網，以便 MetalLB 正常工作。另外，分配給該服務的 IP 地址必須在客戶端用來訪問該服務的網絡所在的同一子網中。
• 使用 L2 工作模式時，所有的節點必須在同一個二層網絡內；必須允許節點之間通過 7946 端口（TCP & UDP，可以配置其他端口）通信，memberlist服務監聽在該端口；二層模式不需要將 IP 綁定到工作節點的網絡接口上。它的工作原理是直接響應本地網絡上的 ARP 請求，將本機的 MAC 地址提供給客戶端
• 從 Kubernetes v1.14.2 開始，若 kube-proxy 使用 IPVS 模式，需要開啟 strict ARP （嚴格的ARP）模式，使用 kubectl edit configmap -n kube-system kube-proxy 修改如下：

apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: "ipvs"
ipvs:
  strictARP: true

通過helm安裝

MetalLBKubernetes manifests、Kustomize 和 Helm 三種安裝方式；這里我們采用helm安裝：

$ helm repo add metallb https://metallb.github.io/metallb
 $ helm search repo -l metallb
 $ helm fetch metallb/metallb --version=0.13.4
 $ tar zxvf metallb-0.13.4.tgz
 #這里我們可以根據自己的需求進行values值的修改，例如原鏡像地（quay.io）址無法拉取，我們可以先拉取然后上傳到自己的鏡像倉庫，然后修改地址
 $ kubectl create namespace metallb-system
 $ helm install metallb -n metallb-system ./metallb

驗證安裝，如下圖所示

在metallb-system的namespace下，會安裝兩個組件：

• controller deployment：負責監聽service資源的變化；依據對應的IP地址池進行IP地址分配的控制器。
• speaker daemonset：負責監聽service資源的變化；通過protocols維護服務間聯通，并依據具體的協議發起對應的廣播和應答、以及節點leader的選舉。

speaker pod 響應 IPv4 服務和 IPv6 的 NDP 請求。

通過manifest安裝

要安裝 MetalLB，使用yaml應用清單：

$ kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.13.4/config/manifests/metallb-native.yaml

配置

由于我們的集群工作在測試環境中，我們采用的是L2工作模式下。

第 2 層模式最容易上手，并且可以在任何環境中工作——不需要花哨的路由器。

定義要分給負載均衡服務的IP地址池。

新版本metallb使用了CR（Custom Resources），這里我們通過IPAddressPool的CR，進行地址池的定義。

如果實例中不設置IPAddressPool選擇器L2Advertisement；那么L2Advertisement默認為該實例所有的IPAddressPool相關聯。

創建metallb-config-ipaddresspool.yaml：

apiVersion: metallb.io/v1beta1
 kind: IPAddressPool
 metadata:
   name: first-pool
   namespace: metallb-system
 spec:
   addresses:
   - 192.168.74.100-192.168.74.110

進行L2關聯地址池的綁定。這里也可以使用標簽選擇器。

創建metallb-config-L2Advertisement.yaml：

apiVersion: metallb.io/v1beta1
 kind: L2Advertisement
 metadata:
   name: example
   namespace: metallb-system
 spec:
   ipAddressPools:
   - first-pool

測試

創建類型為LoadBalancer的SVC進行測試，創建yaml文件tutorial-1.yaml：

apiVersion: apps/v1
 kind: Deployment
 metadata:
   name: nginx
   namespace: default
 spec:
   selector:
     matchLabels:
       app: nginx
   template:
     metadata:
       labels:
         app: nginx
     spec:
       containers:
       - name: nginx
         image: nginx:1
         ports:
         - name: http
           containerPort: 80
 ---
 apiVersion: v1
 kind: Service
 metadata:
   name: nginx
   namespace: default
 spec:
   ports:
   - name: http
     port: 80
     protocol: TCP
     targetPort: 80
   selector:
     app: nginx
   type: LoadBalancer

結果如下圖所示：

通過瀏覽器進行訪問：

參考網址：

• https://access.redhat.com/documentation/zhcn/openshift_container_platform/4.9/html/networking/_load-balancing-with-metallb。
• https://metallb.universe.tf/。