詞匯表

比較開源的 k8s 負載均衡器（LoadBalancer）

在這篇文章中，我們討論了三個開源的負載平衡器控制器，它們可以與任何 Kubernetes 的發行版一起使用。

• MetalLB.[1] 流行的和最知名的 LoabBalancer Controller
• PureLB.[2] 最新加入的。（完全公開，我參與了 PureLB 的開發）
• OpenELB[3]（之前叫：Porter）. 一個相對較近的新增項目，最初只關注路由的問題

添加一個實現服務類型 LoadBalancer 功能的控制器是簡單、可擴展的集群操作所必需的關鍵網絡組件。

• 啟用對集群服務 / 應用的受控外部訪問
• 外部資源是預先配置的
• 易于與自動化工作流程（CI/CD）整合

第一點是顯而易見的，但是后兩點在為你的集群設計負載均衡器解決方案時同樣關鍵。根據部署模式的不同，負責確保集群可靠網絡的團隊與運行集群的團隊不同是很常見的。預配置允許網絡團隊幫助完成設置，并將操作留給集群團隊。這有利于與 CI/CD 的輕松集成，因為使用負載平衡器資源現在是標準的 k8s " 應用 " 定義和工作流程的一部分。

這些獨立的負載均衡器可以在任何 k8s 環境中運行，而不像公有云中使用的集成負載均衡器或 K3s 中的 Klipper 等特定實施捆綁解決方案。

所有的負載均衡器控制器都暴露了服務，每個控制器如何實現這一點是不同的，這種差異影響了操作行為和故障模式。每個負載均衡器控制器都包括一個地址分配器和一個或多個向網絡添加地址的機制，關鍵的區別是用于添加和管理地址的技術。

分配地址

所有的負載均衡器都包括集成的 IP 地址管理（IPAM），用于將 IP 地址從池中分配給服務。它們都有類似的操作：它們觀察 Services API 中沒有 IP 地址的 LoadBalancer 類型，并以 IP 地址更新 kube-api。反過來，其他負載平衡器組件和 kube-proxy 也在觀察服務 API 中包含 IP 地址的 LoadBalancer 類型的事件，并使用該信息來觸發向網絡添加地址。有一個共同的問題影響到分配器和其他組件的操作。服務 API 中用于 IP 地址的類型是一個字符串，包含 a.b.c.d 形式的地址（或者 IPv6 的 a::z）。網絡中使用的 IP 地址通常被稱為前綴，因為它包括子網掩碼，例如 a.b.c.d/ 掩碼（a::z/ 掩碼）。在 golang 中，使用的類型是 ipNet，然而 kube-api 為這個字段使用了一個字符串。這是一個重要的細節，因為它必須由添加地址的過程來處理。

一般來說，有兩種主要的操作類型。

向本地接口添加地址

為本地接口添加地址是小型集群中的第一個要求，但在更大的集群中也可能是有用的，以公布需要從非 k8s 基礎設施組件的本地訪問的服務。然而，添加本地地址并不像它最初看起來那樣簡單。本地網絡接口上的地址必須是唯一的，然而 k8s 以統一的方式協調它所有的節點。因此，必須使用一種機制來識別并確保一個地址只被添加到一個節點上，希望是在所需的網絡上。如果 kube-proxy（用于在集群內編程分配的機制）被配置為 IPVS 模式，這就更加復雜了。

IPVS。kube-proxy 中的 IPVS 實現通過減少對 iptables 的使用來增加可擴展性。在 iptables 輸入鏈中不使用 PREROUTING，而是創建一個假的接口，叫做 kube-ipvs0。Kube-proxy 為 kube-ipvs0 添加負載均衡地址。默認情況下，Linux 內核將回答來自任何接口的 ARP/ND 請求，以獲得任何接口上的地址。這種行為的原因是為了增加成功連接的概率。然而，當地址從本地子網分配時，這就產生了問題，因為所有的主機都響應 ARP/ND，導致重復的 ARP 信息。所有討論的負載均衡器都要求將主機 ARP/ND 模式設置為 “嚴格”，這是對有多個接口的服務器的良好做法。

解決操作問題需要了解地址是如何被添加的以及被添加到哪個節點。了解 k8s 是如何允許向節點添加地址的，這一點很重要。一個使用節點的網絡接口的 POD 被設置為使用hostNetwork:true，允許的能力為NET_ADMIN，在某些情況下設置為NET_RAW。它很容易弄清楚哪些 PODS 被設置為使用主機網絡，POD 的地址將是節點的地址。

將地址添加到路由器上進行分配

將分配的地址添加到網絡路由表中是一個更可擴展和冗余的解決方案。路由允許同一個地址被多個 k8s 節點公布出來。這允許負載均衡器在交換機中填充路由表，以使用等價多路徑，在流量進入集群之前提供一層數據包分配。多個路徑被公布出來，使之成為一個更加冗余的解決方案。然而，重要的是要記住，服務負載均衡器需要與 kube-proxy（集群內流量分配機制）合作。

服務流量策略

externalTrafficPolicy是一個重要的配置設置。它提供了兩種選擇，即如何將流量分配到集群和集群內。當設置為Cluster（默認）時，每個節點都被 kube-proxy 配置為接收并在整個集群內平均分配流量。當設置為本地時，kube-proxy 希望只在運行 POD 的節點上接收流量，本地設置被廣泛用于外部應用，因為這種模式消除了 kube-proxy 對 NAT 的需求，導致源 IP 地址出現在 POD 上，而不是一個 "natted " 節點地址。負載均衡器必須適應這些行為，以實現可靠的流量交付。

開放源碼

所有這些負載均衡器控制器都是開源的，因此文檔覆蓋面也不一樣。在許多情況下，要了解詳細的操作，閱讀源代碼是必要的。

MetalLB

第一個被廣泛部署的 LoadBalancer 是作為 Google 的一個 10% 的項目開始的，直到最近都是尋求開源軟件的負載平衡解決方案的團隊的唯一選擇。它以兩種不同的模式運行，即 L2 模式和 BGP 模式。

MetalLB 是通過 configmap 來配置的。

該控制器由兩個部分組成。

   控制器。分配 IP 地址。每個集群有一個

   發言人 (speaker)。配置節點網絡。在所有節點上運行，提供對 IP 地址的訪問

分配器（控制器）

MetalLB 分配器是非常直接的。地址池是由 configmap 配置的，然而其模式的配置也是地址池配置的一部分。

控制器的行為是一致的，發言人實現了兩種操作模式。在 MetalLB 中，這些模式在 configmap 池中被配置為 “協議”。

L2 Mode

在 MetalLB 中，有兩個關鍵組件共同作用，將地址添加到單個節點上。第一個是使用成員列表的節點選舉。這是一個簡單的選舉方案，使用服務名稱來確保每個節點選擇相同的贏家，即一個分配的 ip 地址將被回答的單一節點。

我使用了回答這個詞，因為在 "L2 " 中，發言人進程實現了 ARP 和 ND。Kube-proxy 已經添加了必要的配置，將流量轉發到目標 POD，ARP/ND 響應仍然是啟動通信的必要條件。

在 L2 模式下，MetalLB 不使用 Linux 網絡來回答 ARP/ND，處理是在發言人的 POD 可執行文件中實現的。因此它的 ARP/ND 處理對 Linux 及其網絡工具來說是不可見的。識別哪個節點在回答 ARP/ND 請求，需要在其他網絡主機上使用 APR/ND 工具，或者檢查發言人 POD 的日志。

Metallb 不知道節點使用的地址范圍，ARP/ND 過程會回答 ConfigMap 中配置的任何網絡地址。這可能導致在 L2 模式下分配的地址無法到達。當節點網絡跨越多個主機子網時，尤其需要注意，不能保證添加的地址會位于具有本地連接的節點上。

BGP Mode

MetalLB 也在 BGP 模式下運行。BGP 提供了一種機制，將前綴（addr/mask）公布給鄰近的路由器。使用路由的機制是利用 Linux 的第三層轉發與路由協議相結合來提供目的地信息。

configmap 配置了 BGP 自治系統信息、對等體信息和池，由協議 bgp 標識。

發言人在每個節點上作為 daemonset 運行，從每個節點到配置的對等路由器建立 BGP 對等連接。AS 號碼標識對等體為外部或內部。

當一個地址從池子里被分配出來時，每個發言人都會把這個地址作為一個主機路由來宣傳。控制器只是從 kube-api 獲取分配的字符串，并通過添加 /32 前綴使所有分配的地址成為主機路由，從而將其變成一個 ipnet。這是公布給 BGP 鄰居的地址。這可能是個問題，因為有些路由器不接受 BGP 的 /32 路由。MetalLB 有一些 BGP 地址聚合功能，但這并不改變 /32 的廣告，它只是告訴上游路由器進行聚合，對等路由器仍然會有 /32 路由。

MetalLB 有自己的 BGP 實現。這很重要，原因有三。

1. MetalLB 使用節點的 IP 地址，是一個路由器。這意味著在默認網絡命名空間中運行的另一個進程，如軟件路由器，不能使用該主機地址與同一路由器對等。在較大的網絡中，這可能導致非常復雜的 BGP 配置。
2. BGP 功能沒有辦法與 Linux 路由表整合，只能用于宣傳 MetalLB 創建的前綴。
3. BGP 功能受限于 MetalLB 的支持水平，其他軟件路由器中的功能需要專門為 MetalLB 開發。MetalLB 有一些額外的 BGP 功能，如聚合和社區支持，但沒有被認為在標準路由器中必須的功能。

這兩種模式都可以同時使用，每種模式都需要特定的配置。

流量策略

MetalLB 支持這種設置，但是在 L2 模式下將 externalTrafficPolicy 設置為 local 可能會導致丟包，不應使用。在 BGP 模式下，只有有 POD 的節點才會被公布。流量將在運行 POD 的節點之間平均分配，但每個節點都將收到相同的份額，而不考慮該節點上的 pod 數量。

配置

MetalLB 是使用 configmaps 來配置的。在最初開發時，這是用于配置的主要機制，現在許多控制器仍然使用。configmaps 的問題是，在應用 POD 讀取配置之前，沒有辦法驗證它。因此，不正確的配置會導致 POD 失敗或不正確的操作，" 失敗后 " 只能通過查看個別 POD 的日志來調試 。

這進一步增加了 configmap 的復雜性，MetalLB 有一個奇怪的配置行為，值得在其部署前了解。不正確的配置變化會導致 configmap 被標記為過時。舊的配置作為注釋存儲在 configmap 中，繼續被使用。例如，一旦定義并使用，改變地址池是很困難的。如果一個服務使用現有池中的地址，就不能改變池的配置。改變池子標志著配置的陳舊，MetalLB 繼續使用同一個地址池，新的服務從舊的池子中分配。知道配置是否過時的唯一方法是檢查 MetalLB POD 日志。如果發言人被手動重啟或通過節點故障重啟，舊的地址分配將保留，然而如果控制器被重啟，所有服務將被重新編號為新的配置。如果控制器或發言人以無效的配置重新啟動，并且配置無效，那么最后的配置將從 configmap 注釋中加載。要注意通過檢查發言人日志，確保每一個 configmap 的變化都是有效的。一個分配了大量地址的 " 陳舊 " 的配置可能很難在不遭受停機的情況下退掉。

MetalLB 的文檔很充分，但很稀少。要了解它的運作方式，有必要閱讀源代碼。

IPv6

在檢查源代碼時，你會發現 MetalLB 的一些組件支持 IPv6，但作為一個系統，MetalLB 并不支持 IPv6。添加地址池會導致控制器和發言人中加載的配置失效，變得 “陳舊”。

MetalLB 總結

MetalLB 不使用原生的 Linux 網絡，因此很難使用標準的 Linux 工具進行故障排除。它有自己獨特的 BGP 實現，缺乏用于管理大規模 BGP 基礎設施的功能。增加這些功能需要 BGP 協議的開發，雖然有可能，但要使 BGP 實現的功能齊全需要大量的開發工作。因為它是一個 BGP 路由器，使用 BGP for CNI 的節點不能同時將 BGP for CNI 和 BGP 從 MetalLB 對接到同一個上游路由器。有一些拓撲結構的解決辦法，但它們給路由基礎設施增加了很大的復雜性。

PureLB

PureLB 是最新的開源負載均衡器。檢查代碼會發現，它是作為 MetalLB 的一個分叉開始的，但是操作方式非常不同。PureLB 沒有 " 操作 " 或協議模式，它自動從包含地址池的服務組分配地址給不同的接口。這些接口響應本地網絡請求或通過獨立的路由軟件分配路由。

PureLB 是使用自定義資源（CRD）配置的。

該控制器由兩部分組成。

• 分配器。分配 IP 地址。每個集群有一個
• lbnodeagent . 配置節點網絡。在所有節點上運行，提供對 IP 地址的訪問。

PureLB 沒有 “協議模式”，只是包含地址的服務組。PureLB 使用 Linux 網絡功能來添加本地使用的地址，并由路由器重新分配。所需的配置很少，但在需要特定網絡接口時，可以在自定義資源中覆蓋接口默認值。

分配器

PureLB 的分配器包括一個集成的 IPAM，但也支持外部 IPAM 系統。目前唯一支持的外部 IPAM 是流行的開放源碼 NetBox。分配器是使用自定義資源配置的。每個地址池都包含在一個獨特的服務組中。服務組包含其他網絡信息，允許 lbnodeagent 構建所需的前綴或添加的 IPNet。無論地址如何使用，分配器的行為都是一致的，不需要 " 協議 " 配置。

本地網絡地址

在 PureLB 中，" 本地 " 地址是作為二級地址添加到節點主網絡接口的地址。PureLB 通過識別哪個接口有默認路由來識別主網絡適配器。當一個地址從地址池中分配，而該地址與主網絡接口前綴相匹配時，PureLB 使用成員列表選出一個節點，并將該地址作為二級地址添加到接口上。

由于地址是作為二級網絡接口添加的，Linux 網絡響應 ARP/ND 請求，PureLB 并沒有實現自己的 ARP/ND 進程。此外，使用標準的 Linux 網絡工具，如 iproute2，地址是可見的，所以可以用標準的 Linux 工具找到地址的分配位置。

此外，當 PureLB 分配一個地址時，服務被注釋為 IPAM 源和分配的地址。在本地地址的情況下，當選的節點和接口也被作為注釋添加到服務中作為注釋。

PureLB 知道節點網絡，因此只有與本地網絡相匹配的服務組池才會被應用于本地接口。這確保了已建立本地連接的地址可以被訪問，需要路由的地址將使用虛擬接口機制。

虛擬網絡地址

PureLB 將服務組池中與本地節點接口不匹配的地址添加到一個名為 kube-lb0 的虛擬接口。lbnodeagent 會在 POD 啟動時添加該接口。

虛擬接口可用于添加任何將通過路由訪問的網絡，為了實現高效的路由，PureLB 允許在添加地址時使用默認或配置的地址聚合掩碼。在服務組中添加的這個掩碼被應用于創建添加到虛擬接口的 ipNet。Linux 內核負責將地址添加到接口并創建正確的路由。這使得在使用 externalTrafficPolicy: cluster 的情況下，一個子網可以被公布一次，或者在設置為本地時，一個主機路由可以被公布。網絡設計者使用地址聚合來控制路由表的大小，支持聚合提供大規模的網絡靈活性。

路由協議

PureLB 不直接實現任何需要添加軟件路由器的路由協議，以分配添加到虛擬接口的地址的可達性。在集群沒有路由軟件用于基礎設施或 CNI 的情況下，PureLB 提供一個捆綁的、預配置的 BIRD 路由器守護程序。路由器被配置為使用一個名為 " 重新分配 " 的通用功能來讀取與虛擬接口相關的路由，并使用配置的路由協議進行分配。

利用這種機制，所使用的路由軟件支持的任何路由協議都可以用來分配負載均衡器的地址，路由協議的開發與負載均衡器脫鉤。成套的 BIRD 路由器支持 BGP、OSPF、RIP，用于 IPv4 和 IPv6。其他如 FRR 也支持 ISIS 和 IGRP，商業路由軟件也可以使用。這種機制的主要好處之一是，路由軟件提供了每個路由協議的完整實現，允許在設計網絡和如何分配路由方面有最大的靈活性。在一個使用 OSPF 實現可達性的網絡中，可以使用 OSPF 分配負載平衡器地址，而不需要增加 BGP。

當 CNI 沒有被配置為使用隧道和 POD 網絡跨越多個子網時，就需要路由協議。在某些情況下，CNI 的包括路由功能作為其操作的一部分。在這些情況下，PureLB 可以避免因試圖在同一節點上運行兩個路由實例而引起的問題。CNI 的路由過程只是重新分配來自虛擬接口的路由，并應用任何必要的路由策略，創造一個更簡單、更自然的路由拓撲結構。

流量策略

PureLB 支持虛擬網絡地址的externalTrafficPolicy:local。只有當 POD 存在時，虛擬網絡地址才會被添加到一個節點上。流量將在運行 POD 的節點之間平均分配，然而每個節點將收到相等的份額，無論該節點上有多少 POD。PureLB 不支持本地網絡地址的externalTrafficPolicy:local，事實上，如果你試圖將本地網絡地址的 externalTrafficPolicy 設置為 local，PureLB 會將其重置為Cluster，以確保 kube-proxy 的配置正確，流量將到達所有選定的 POD

配置

PureLB 的配置是通過自定義資源。整個系統配置有一個 CR，每個服務組有一個 CR。由于每個 CR 都是獨立的，并且 CR 可以在創建時進行驗證，PureLB 保持了一致的配置，地址池可以根據需要進行更改。PureLB 永遠不會改變已經分配的地址，它希望地址的改變是一種故意的行為，因此地址的改變需要添加 / 刪除一個服務。

隨著 PureLB 的運行，它向提供負載平衡服務的服務添加注釋，以及更新服務事件日志，因此可以從服務中提取關鍵服務信息和狀態，而不需要檢查 POD 日志。

IPv6

PureLB 包括對 IPv6 的支持。定義了一個服務組，其中包括地址和網絡信息，當使用該池時，會在本地或虛擬中添加 IPv6 地址。為了通過路由協議進行分配，需要在軟件路由器中配置相應的 IPv6 路由協議，打包的 BIRD 路由器支持 IPv6。

總結

這款新產品通過提供外部 IPAM、IPv6，更重要的是利用 Linux 網絡，使自己與眾不同。PureLB 沒有試圖重新發明網絡和路由協議，而是能夠使用所有的 Linux 和路由功能。在復雜的基礎設施中，PureLB 更容易實現，因為在這些基礎設施中，路由需要其他方面的可達性，如 CNI、存儲或管理網絡，并且已經在集群中存在。檢查代碼可以看出 PureLB 與分叉出來的 MetalLB 版本有多大區別，其簡單性表現在它的代碼行數只有一半左右。

OpenELB（Porter）

Porter 是一個相對較新的開源負載均衡器的補充。它是一個獨立的開發項目。最初只有 BGP，最近加入了本地地址支持。Porter 的不同之處在于它在控制器和代理之間分配功能的方式。Porter 也實現了 BGP，但需要在本地網絡上有一個 BGP 路由器，并有一個自定義的端口配置。

Porter 是使用自定義資源配置的。

該控制器由兩部分組成。

• porter-manager。分配地址和配置網絡功能。
• porter-agent。收集節點的具體信息，由 porter-manager 用來配置網絡。

分配器

分配器是 porter-manager 的一部分。有一個 porter-manager 的單一實例。池被配置在稱為 EIP 的自定義資源中。這包含地址和用于地址可達性的協議。

注意，porter 沒有任何默認負載均衡器地址池的概念，注釋總是需要的。

Porter 把網絡配置集中在 porter-manager 中，porter-agent 只是收集事件，添加節點的具體信息，并把這些信息返回給 porter-manager。

L2

在 L2 模式下，Porter 不使用 Linux 網絡。porter-manager 可執行程序實現了它自己的 ARP 進程。當一個地址從 EIP 池中分配時，porter-manager 代表目標節點回答對該地址的請求。服務的 ARP 過程集中在管理器中。雖然這種機制應該是有效的，但它并不嚴格符合 ARP 處理的運作方式。porter-manager 回答初始請求，因為它們是廣播。然而，APR 緩存處理使用單播 ARP 消息來驗證緩存條目，只有在單播 ARP 失敗時才回落到廣播。porter-manager 將不回答單播 ARP 請求。這增加了廣播流量，并依賴于非標準的操作行為。跟蹤硬件 mac 地址的第二層交換機安全機制可能會干擾這種操作，導致第二層功能失敗。

使 L2 實現的問題更加復雜的是，當一個部署被擴展或存在一個守護集時，porter-manager 會錯誤地響應每個運行 pod 的節點的 mac 地址，有效地表現為網絡上有重復的 ip 地址。唯一可以使用 L2 模式的時間是集群上的單個 POD。

最后，繼續運行取決于 porter-manager，porter-manager 使用標準的 k8s POD 故障檢測機制，因此 porter-manager 可能需要大量的時間來重新啟動，影響到新的和現有的服務，因為它們將沒有 ARP 響應。

BGP

Porter 使用 gobgp 實現了 BGP，但是它實現了 gobgp 功能的一個非常小的子集。Porter BGP 的實現只具有與本地網段的路由器對等的必要功能。

Porter 從 porter-manager 節點為集群建立單個 BGP 對等體。BGP 對等體必須是在本地網段上，因為不可能配置 BGP 多跳。

當一個服務被定義時，porter-manager 會公布分配的地址，其下一跳是運行容器的節點。擴大部署，使 POD 分布在多個節點上，會導致為 ECMP 添加額外的路由。每個分配的地址都被轉換為一個主機路由（/32）。然而，這種流量策略行為是不正確的，下面將詳細介紹。

另外，Porter 聲稱支持 AddPath，這是一個為單一路由添加多個并發路徑的機制。這個功能的使用似乎有些混亂，從 MetalLB 的一個帖子開始，建議這可能是一種機制，以更好地平衡流量分配到有多個 POD 的節點上。這不是 addpath 的目的，它被用來提供路由表的穩定性，在這種情況下，多個路徑通常會被匯總。如果他們的實施方案使用 addpath 來為同一個節點增加更多的 ECMP 下一跳，這可能是某一特定廠商的行為。不管怎么說，大多數 BGP 實現都會顯示 addpath 計數，我們沒有看到 porter-manager 在上游路由器上更新這些計數以反映節點上的 POD 數量。

BGP 進程作為 porter-manager 的一部分運行，因此 porter manager 的故障會導致上游路由器的對等體宕機，軟件路由器將撤回它從 porter 學到的所有路由。

為了解決一個節點上有兩個路由器造成的問題，porter 用不同的端口號連接到上游的路由器。它解決了部分問題，必須注意手動配置路由器 -ID，而不是通過使用主機 IP 地址創建一個重復的路由器。

流量策略

在 Porter 中改變 externalTrafficPolicy:local 確實改變了其操作。Porter 總是將流量發送到有 POD 的節點或節點。這違反了 kubernetes 描述的行為。在 BGP 模式下，所有的服務都應該被設置為 externalTafficPolicy:Local，因為這是 Porter 的行為方式，不管這個配置如何。這種設置將導致 kube-proxy 的正確配置，刪除一個不必要的 NAT 步驟，并保留源 IP 地址。波特的第二層操作有多個 POD，導致重復的 IP 地址，因此進一步討論這個設置如何影響現有的不正確的網絡行為是不相關的。

配置

配置是通過自定義資源，每個 EIP 包含一個地址范圍和相關協議。

L2 不需要進一步的配置，但是有兩個 BGP 的 CR，BgpConf和 BgpPeer。BgpConf 要求定義RouterID，這進一步強調了 BGP 的有限實施。按照慣例，這將是主機設備上的一個地址。然而，這將是混亂的，因為 Kubernetes 安排了這個 POD，因此應該使用另一個地址作為靜態標識符。與大多數實現不同的是，Porter 沒有一個機制來自動選擇一個有效的地址。

在討論配置問題時，Porter 的文檔非常有限。它可以從文檔中安裝和配置，然而，如果你的評估需要你弄清楚它是如何工作的，請準備閱讀 golang 代碼。

IPv6

Porter 沒有對 IPv6 的支持。掃描代碼時沒有發現有任何 IPv6 支持。

總結

構建這些負載平衡器協調器并不容易！K8s 網絡與主機和路由協議的結合需要大量的知識和技能。因此，我贊揚開發者的工作。

引用鏈接

[1] MetalLB.: https://metallb.universe.tf/

[2] PureLB.: https://purelb.gitlab.io/docs/

[3] OpenELB: https://github.com/kubesphere/openelb