詞匯表

比較開源的 k8s 負(fù)載均衡器（LoadBalancer）

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

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

添加一個(gè)實(shí)現(xiàn)服務(wù)類型 LoadBalancer 功能的控制器是簡(jiǎn)單、可擴(kuò)展的集群操作所必需的關(guān)鍵網(wǎng)絡(luò)組件。

• 啟用對(duì)集群服務(wù) / 應(yīng)用的受控外部訪問
• 外部資源是預(yù)先配置的
• 易于與自動(dòng)化工作流程（CI/CD）整合

第一點(diǎn)是顯而易見的，但是后兩點(diǎn)在為你的集群設(shè)計(jì)負(fù)載均衡器解決方案時(shí)同樣關(guān)鍵。根據(jù)部署模式的不同，負(fù)責(zé)確保集群可靠網(wǎng)絡(luò)的團(tuán)隊(duì)與運(yùn)行集群的團(tuán)隊(duì)不同是很常見的。預(yù)配置允許網(wǎng)絡(luò)團(tuán)隊(duì)幫助完成設(shè)置，并將操作留給集群團(tuán)隊(duì)。這有利于與 CI/CD 的輕松集成，因?yàn)槭褂秘?fù)載平衡器資源現(xiàn)在是標(biāo)準(zhǔn)的 k8s " 應(yīng)用 " 定義和工作流程的一部分。

這些獨(dú)立的負(fù)載均衡器可以在任何 k8s 環(huán)境中運(yùn)行，而不像公有云中使用的集成負(fù)載均衡器或 K3s 中的 Klipper 等特定實(shí)施捆綁解決方案。

所有的負(fù)載均衡器控制器都暴露了服務(wù)，每個(gè)控制器如何實(shí)現(xiàn)這一點(diǎn)是不同的，這種差異影響了操作行為和故障模式。每個(gè)負(fù)載均衡器控制器都包括一個(gè)地址分配器和一個(gè)或多個(gè)向網(wǎng)絡(luò)添加地址的機(jī)制，關(guān)鍵的區(qū)別是用于添加和管理地址的技術(shù)。

分配地址

所有的負(fù)載均衡器都包括集成的 IP 地址管理（IPAM），用于將 IP 地址從池中分配給服務(wù)。它們都有類似的操作：它們觀察 Services API 中沒有 IP 地址的 LoadBalancer 類型，并以 IP 地址更新 kube-api。反過來，其他負(fù)載平衡器組件和 kube-proxy 也在觀察服務(wù) API 中包含 IP 地址的 LoadBalancer 類型的事件，并使用該信息來觸發(fā)向網(wǎng)絡(luò)添加地址。有一個(gè)共同的問題影響到分配器和其他組件的操作。服務(wù) API 中用于 IP 地址的類型是一個(gè)字符串，包含 a.b.c.d 形式的地址（或者 IPv6 的 a::z）。網(wǎng)絡(luò)中使用的 IP 地址通常被稱為前綴，因?yàn)樗ㄗ泳W(wǎng)掩碼，例如 a.b.c.d/ 掩碼（a::z/ 掩碼）。在 golang 中，使用的類型是 ipNet，然而 kube-api 為這個(gè)字段使用了一個(gè)字符串。這是一個(gè)重要的細(xì)節(jié)，因?yàn)樗仨氂商砑拥刂返倪^程來處理。

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

向本地接口添加地址

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

IPVS。kube-proxy 中的 IPVS 實(shí)現(xiàn)通過減少對(duì) iptables 的使用來增加可擴(kuò)展性。在 iptables 輸入鏈中不使用 PREROUTING，而是創(chuàng)建一個(gè)假的接口，叫做 kube-ipvs0。Kube-proxy 為 kube-ipvs0 添加負(fù)載均衡地址。默認(rèn)情況下，Linux 內(nèi)核將回答來自任何接口的 ARP/ND 請(qǐng)求，以獲得任何接口上的地址。這種行為的原因是為了增加成功連接的概率。然而，當(dāng)?shù)刂窂谋镜刈泳W(wǎng)分配時(shí)，這就產(chǎn)生了問題，因?yàn)樗械闹鳈C(jī)都響應(yīng) ARP/ND，導(dǎo)致重復(fù)的 ARP 信息。所有討論的負(fù)載均衡器都要求將主機(jī) ARP/ND 模式設(shè)置為 “嚴(yán)格”，這是對(duì)有多個(gè)接口的服務(wù)器的良好做法。

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

將地址添加到路由器上進(jìn)行分配

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

服務(wù)流量策略

externalTrafficPolicy是一個(gè)重要的配置設(shè)置。它提供了兩種選擇，即如何將流量分配到集群和集群內(nèi)。當(dāng)設(shè)置為Cluster（默認(rèn)）時(shí)，每個(gè)節(jié)點(diǎn)都被 kube-proxy 配置為接收并在整個(gè)集群內(nèi)平均分配流量。當(dāng)設(shè)置為本地時(shí)，kube-proxy 希望只在運(yùn)行 POD 的節(jié)點(diǎn)上接收流量，本地設(shè)置被廣泛用于外部應(yīng)用，因?yàn)檫@種模式消除了 kube-proxy 對(duì) NAT 的需求，導(dǎo)致源 IP 地址出現(xiàn)在 POD 上，而不是一個(gè) "natted " 節(jié)點(diǎn)地址。負(fù)載均衡器必須適應(yīng)這些行為，以實(shí)現(xiàn)可靠的流量交付。

開放源碼

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

MetalLB

第一個(gè)被廣泛部署的 LoadBalancer 是作為 Google 的一個(gè) 10% 的項(xiàng)目開始的，直到最近都是尋求開源軟件的負(fù)載平衡解決方案的團(tuán)隊(duì)的唯一選擇。它以兩種不同的模式運(yùn)行，即 L2 模式和 BGP 模式。

MetalLB 是通過 configmap 來配置的。

該控制器由兩個(gè)部分組成。

   控制器。分配 IP 地址。每個(gè)集群有一個(gè)

   發(fā)言人 (speaker)。配置節(jié)點(diǎn)網(wǎng)絡(luò)。在所有節(jié)點(diǎn)上運(yùn)行，提供對(duì) IP 地址的訪問

分配器（控制器）

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

控制器的行為是一致的，發(fā)言人實(shí)現(xiàn)了兩種操作模式。在 MetalLB 中，這些模式在 configmap 池中被配置為 “協(xié)議”。

L2 Mode

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

我使用了回答這個(gè)詞，因?yàn)樵?"L2 " 中，發(fā)言人進(jìn)程實(shí)現(xiàn)了 ARP 和 ND。Kube-proxy 已經(jīng)添加了必要的配置，將流量轉(zhuǎn)發(fā)到目標(biāo) POD，ARP/ND 響應(yīng)仍然是啟動(dòng)通信的必要條件。

在 L2 模式下，MetalLB 不使用 Linux 網(wǎng)絡(luò)來回答 ARP/ND，處理是在發(fā)言人的 POD 可執(zhí)行文件中實(shí)現(xiàn)的。因此它的 ARP/ND 處理對(duì) Linux 及其網(wǎng)絡(luò)工具來說是不可見的。識(shí)別哪個(gè)節(jié)點(diǎn)在回答 ARP/ND 請(qǐng)求，需要在其他網(wǎng)絡(luò)主機(jī)上使用 APR/ND 工具，或者檢查發(fā)言人 POD 的日志。

Metallb 不知道節(jié)點(diǎn)使用的地址范圍，ARP/ND 過程會(huì)回答 ConfigMap 中配置的任何網(wǎng)絡(luò)地址。這可能導(dǎo)致在 L2 模式下分配的地址無法到達(dá)。當(dāng)節(jié)點(diǎn)網(wǎng)絡(luò)跨越多個(gè)主機(jī)子網(wǎng)時(shí)，尤其需要注意，不能保證添加的地址會(huì)位于具有本地連接的節(jié)點(diǎn)上。

BGP Mode

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

configmap 配置了 BGP 自治系統(tǒng)信息、對(duì)等體信息和池，由協(xié)議 bgp 標(biāo)識(shí)。

發(fā)言人在每個(gè)節(jié)點(diǎn)上作為 daemonset 運(yùn)行，從每個(gè)節(jié)點(diǎn)到配置的對(duì)等路由器建立 BGP 對(duì)等連接。AS 號(hào)碼標(biāo)識(shí)對(duì)等體為外部或內(nèi)部。

當(dāng)一個(gè)地址從池子里被分配出來時(shí)，每個(gè)發(fā)言人都會(huì)把這個(gè)地址作為一個(gè)主機(jī)路由來宣傳。控制器只是從 kube-api 獲取分配的字符串，并通過添加 /32 前綴使所有分配的地址成為主機(jī)路由，從而將其變成一個(gè) ipnet。這是公布給 BGP 鄰居的地址。這可能是個(gè)問題，因?yàn)橛行┞酚善鞑唤邮?BGP 的 /32 路由。MetalLB 有一些 BGP 地址聚合功能，但這并不改變 /32 的廣告，它只是告訴上游路由器進(jìn)行聚合，對(duì)等路由器仍然會(huì)有 /32 路由。

MetalLB 有自己的 BGP 實(shí)現(xiàn)。這很重要，原因有三。

1. MetalLB 使用節(jié)點(diǎn)的 IP 地址，是一個(gè)路由器。這意味著在默認(rèn)網(wǎng)絡(luò)命名空間中運(yùn)行的另一個(gè)進(jìn)程，如軟件路由器，不能使用該主機(jī)地址與同一路由器對(duì)等。在較大的網(wǎng)絡(luò)中，這可能導(dǎo)致非常復(fù)雜的 BGP 配置。
2. BGP 功能沒有辦法與 Linux 路由表整合，只能用于宣傳 MetalLB 創(chuàng)建的前綴。
3. BGP 功能受限于 MetalLB 的支持水平，其他軟件路由器中的功能需要專門為 MetalLB 開發(fā)。MetalLB 有一些額外的 BGP 功能，如聚合和社區(qū)支持，但沒有被認(rèn)為在標(biāo)準(zhǔn)路由器中必須的功能。

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

流量策略

MetalLB 支持這種設(shè)置，但是在 L2 模式下將 externalTrafficPolicy 設(shè)置為 local 可能會(huì)導(dǎo)致丟包，不應(yīng)使用。在 BGP 模式下，只有有 POD 的節(jié)點(diǎn)才會(huì)被公布。流量將在運(yùn)行 POD 的節(jié)點(diǎn)之間平均分配，但每個(gè)節(jié)點(diǎn)都將收到相同的份額，而不考慮該節(jié)點(diǎn)上的 pod 數(shù)量。

配置

MetalLB 是使用 configmaps 來配置的。在最初開發(fā)時(shí)，這是用于配置的主要機(jī)制，現(xiàn)在許多控制器仍然使用。configmaps 的問題是，在應(yīng)用 POD 讀取配置之前，沒有辦法驗(yàn)證它。因此，不正確的配置會(huì)導(dǎo)致 POD 失敗或不正確的操作，" 失敗后 " 只能通過查看個(gè)別 POD 的日志來調(diào)試 。

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

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

IPv6

在檢查源代碼時(shí)，你會(huì)發(fā)現(xiàn) MetalLB 的一些組件支持 IPv6，但作為一個(gè)系統(tǒng)，MetalLB 并不支持 IPv6。添加地址池會(huì)導(dǎo)致控制器和發(fā)言人中加載的配置失效，變得 “陳舊”。

MetalLB 總結(jié)

MetalLB 不使用原生的 Linux 網(wǎng)絡(luò)，因此很難使用標(biāo)準(zhǔn)的 Linux 工具進(jìn)行故障排除。它有自己獨(dú)特的 BGP 實(shí)現(xiàn)，缺乏用于管理大規(guī)模 BGP 基礎(chǔ)設(shè)施的功能。增加這些功能需要 BGP 協(xié)議的開發(fā)，雖然有可能，但要使 BGP 實(shí)現(xiàn)的功能齊全需要大量的開發(fā)工作。因?yàn)樗且粋€(gè) BGP 路由器，使用 BGP for CNI 的節(jié)點(diǎn)不能同時(shí)將 BGP for CNI 和 BGP 從 MetalLB 對(duì)接到同一個(gè)上游路由器。有一些拓?fù)浣Y(jié)構(gòu)的解決辦法，但它們給路由基礎(chǔ)設(shè)施增加了很大的復(fù)雜性。

PureLB

PureLB 是最新的開源負(fù)載均衡器。檢查代碼會(huì)發(fā)現(xiàn)，它是作為 MetalLB 的一個(gè)分叉開始的，但是操作方式非常不同。PureLB 沒有 " 操作 " 或協(xié)議模式，它自動(dòng)從包含地址池的服務(wù)組分配地址給不同的接口。這些接口響應(yīng)本地網(wǎng)絡(luò)請(qǐng)求或通過獨(dú)立的路由軟件分配路由。

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

該控制器由兩部分組成。

• 分配器。分配 IP 地址。每個(gè)集群有一個(gè)
• lbnodeagent . 配置節(jié)點(diǎn)網(wǎng)絡(luò)。在所有節(jié)點(diǎn)上運(yùn)行，提供對(duì) IP 地址的訪問。

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

分配器

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

本地網(wǎng)絡(luò)地址

在 PureLB 中，" 本地 " 地址是作為二級(jí)地址添加到節(jié)點(diǎn)主網(wǎng)絡(luò)接口的地址。PureLB 通過識(shí)別哪個(gè)接口有默認(rèn)路由來識(shí)別主網(wǎng)絡(luò)適配器。當(dāng)一個(gè)地址從地址池中分配，而該地址與主網(wǎng)絡(luò)接口前綴相匹配時(shí)，PureLB 使用成員列表選出一個(gè)節(jié)點(diǎn)，并將該地址作為二級(jí)地址添加到接口上。

由于地址是作為二級(jí)網(wǎng)絡(luò)接口添加的，Linux 網(wǎng)絡(luò)響應(yīng) ARP/ND 請(qǐng)求，PureLB 并沒有實(shí)現(xiàn)自己的 ARP/ND 進(jìn)程。此外，使用標(biāo)準(zhǔn)的 Linux 網(wǎng)絡(luò)工具，如 iproute2，地址是可見的，所以可以用標(biāo)準(zhǔn)的 Linux 工具找到地址的分配位置。

此外，當(dāng) PureLB 分配一個(gè)地址時(shí)，服務(wù)被注釋為 IPAM 源和分配的地址。在本地地址的情況下，當(dāng)選的節(jié)點(diǎn)和接口也被作為注釋添加到服務(wù)中作為注釋。

PureLB 知道節(jié)點(diǎn)網(wǎng)絡(luò)，因此只有與本地網(wǎng)絡(luò)相匹配的服務(wù)組池才會(huì)被應(yīng)用于本地接口。這確保了已建立本地連接的地址可以被訪問，需要路由的地址將使用虛擬接口機(jī)制。

虛擬網(wǎng)絡(luò)地址

PureLB 將服務(wù)組池中與本地節(jié)點(diǎn)接口不匹配的地址添加到一個(gè)名為 kube-lb0 的虛擬接口。lbnodeagent 會(huì)在 POD 啟動(dòng)時(shí)添加該接口。

虛擬接口可用于添加任何將通過路由訪問的網(wǎng)絡(luò)，為了實(shí)現(xiàn)高效的路由，PureLB 允許在添加地址時(shí)使用默認(rèn)或配置的地址聚合掩碼。在服務(wù)組中添加的這個(gè)掩碼被應(yīng)用于創(chuàng)建添加到虛擬接口的 ipNet。Linux 內(nèi)核負(fù)責(zé)將地址添加到接口并創(chuàng)建正確的路由。這使得在使用 externalTrafficPolicy: cluster 的情況下，一個(gè)子網(wǎng)可以被公布一次，或者在設(shè)置為本地時(shí)，一個(gè)主機(jī)路由可以被公布。網(wǎng)絡(luò)設(shè)計(jì)者使用地址聚合來控制路由表的大小，支持聚合提供大規(guī)模的網(wǎng)絡(luò)靈活性。

路由協(xié)議

PureLB 不直接實(shí)現(xiàn)任何需要添加軟件路由器的路由協(xié)議，以分配添加到虛擬接口的地址的可達(dá)性。在集群沒有路由軟件用于基礎(chǔ)設(shè)施或 CNI 的情況下，PureLB 提供一個(gè)捆綁的、預(yù)配置的 BIRD 路由器守護(hù)程序。路由器被配置為使用一個(gè)名為 " 重新分配 " 的通用功能來讀取與虛擬接口相關(guān)的路由，并使用配置的路由協(xié)議進(jìn)行分配。

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

當(dāng) CNI 沒有被配置為使用隧道和 POD 網(wǎng)絡(luò)跨越多個(gè)子網(wǎng)時(shí)，就需要路由協(xié)議。在某些情況下，CNI 的包括路由功能作為其操作的一部分。在這些情況下，PureLB 可以避免因試圖在同一節(jié)點(diǎn)上運(yùn)行兩個(gè)路由實(shí)例而引起的問題。CNI 的路由過程只是重新分配來自虛擬接口的路由，并應(yīng)用任何必要的路由策略，創(chuàng)造一個(gè)更簡(jiǎn)單、更自然的路由拓?fù)浣Y(jié)構(gòu)。

流量策略

PureLB 支持虛擬網(wǎng)絡(luò)地址的externalTrafficPolicy:local。只有當(dāng) POD 存在時(shí)，虛擬網(wǎng)絡(luò)地址才會(huì)被添加到一個(gè)節(jié)點(diǎn)上。流量將在運(yùn)行 POD 的節(jié)點(diǎn)之間平均分配，然而每個(gè)節(jié)點(diǎn)將收到相等的份額，無論該節(jié)點(diǎn)上有多少 POD。PureLB 不支持本地網(wǎng)絡(luò)地址的externalTrafficPolicy:local，事實(shí)上，如果你試圖將本地網(wǎng)絡(luò)地址的 externalTrafficPolicy 設(shè)置為 local，PureLB 會(huì)將其重置為Cluster，以確保 kube-proxy 的配置正確，流量將到達(dá)所有選定的 POD

配置

PureLB 的配置是通過自定義資源。整個(gè)系統(tǒng)配置有一個(gè) CR，每個(gè)服務(wù)組有一個(gè) CR。由于每個(gè) CR 都是獨(dú)立的，并且 CR 可以在創(chuàng)建時(shí)進(jìn)行驗(yàn)證，PureLB 保持了一致的配置，地址池可以根據(jù)需要進(jìn)行更改。PureLB 永遠(yuǎn)不會(huì)改變已經(jīng)分配的地址，它希望地址的改變是一種故意的行為，因此地址的改變需要添加 / 刪除一個(gè)服務(wù)。

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

IPv6

PureLB 包括對(duì) IPv6 的支持。定義了一個(gè)服務(wù)組，其中包括地址和網(wǎng)絡(luò)信息，當(dāng)使用該池時(shí)，會(huì)在本地或虛擬中添加 IPv6 地址。為了通過路由協(xié)議進(jìn)行分配，需要在軟件路由器中配置相應(yīng)的 IPv6 路由協(xié)議，打包的 BIRD 路由器支持 IPv6。

總結(jié)

這款新產(chǎn)品通過提供外部 IPAM、IPv6，更重要的是利用 Linux 網(wǎng)絡(luò)，使自己與眾不同。PureLB 沒有試圖重新發(fā)明網(wǎng)絡(luò)和路由協(xié)議，而是能夠使用所有的 Linux 和路由功能。在復(fù)雜的基礎(chǔ)設(shè)施中，PureLB 更容易實(shí)現(xiàn)，因?yàn)樵谶@些基礎(chǔ)設(shè)施中，路由需要其他方面的可達(dá)性，如 CNI、存儲(chǔ)或管理網(wǎng)絡(luò)，并且已經(jīng)在集群中存在。檢查代碼可以看出 PureLB 與分叉出來的 MetalLB 版本有多大區(qū)別，其簡(jiǎn)單性表現(xiàn)在它的代碼行數(shù)只有一半左右。

OpenELB（Porter）

Porter 是一個(gè)相對(duì)較新的開源負(fù)載均衡器的補(bǔ)充。它是一個(gè)獨(dú)立的開發(fā)項(xiàng)目。最初只有 BGP，最近加入了本地地址支持。Porter 的不同之處在于它在控制器和代理之間分配功能的方式。Porter 也實(shí)現(xiàn)了 BGP，但需要在本地網(wǎng)絡(luò)上有一個(gè) BGP 路由器，并有一個(gè)自定義的端口配置。

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

該控制器由兩部分組成。

• porter-manager。分配地址和配置網(wǎng)絡(luò)功能。
• porter-agent。收集節(jié)點(diǎn)的具體信息，由 porter-manager 用來配置網(wǎng)絡(luò)。

分配器

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

注意，porter 沒有任何默認(rèn)負(fù)載均衡器地址池的概念，注釋總是需要的。

Porter 把網(wǎng)絡(luò)配置集中在 porter-manager 中，porter-agent 只是收集事件，添加節(jié)點(diǎn)的具體信息，并把這些信息返回給 porter-manager。

L2

在 L2 模式下，Porter 不使用 Linux 網(wǎng)絡(luò)。porter-manager 可執(zhí)行程序?qū)崿F(xiàn)了它自己的 ARP 進(jìn)程。當(dāng)一個(gè)地址從 EIP 池中分配時(shí)，porter-manager 代表目標(biāo)節(jié)點(diǎn)回答對(duì)該地址的請(qǐng)求。服務(wù)的 ARP 過程集中在管理器中。雖然這種機(jī)制應(yīng)該是有效的，但它并不嚴(yán)格符合 ARP 處理的運(yùn)作方式。porter-manager 回答初始請(qǐng)求，因?yàn)樗鼈兪菑V播。然而，APR 緩存處理使用單播 ARP 消息來驗(yàn)證緩存條目，只有在單播 ARP 失敗時(shí)才回落到廣播。porter-manager 將不回答單播 ARP 請(qǐng)求。這增加了廣播流量，并依賴于非標(biāo)準(zhǔn)的操作行為。跟蹤硬件 mac 地址的第二層交換機(jī)安全機(jī)制可能會(huì)干擾這種操作，導(dǎo)致第二層功能失敗。

使 L2 實(shí)現(xiàn)的問題更加復(fù)雜的是，當(dāng)一個(gè)部署被擴(kuò)展或存在一個(gè)守護(hù)集時(shí)，porter-manager 會(huì)錯(cuò)誤地響應(yīng)每個(gè)運(yùn)行 pod 的節(jié)點(diǎn)的 mac 地址，有效地表現(xiàn)為網(wǎng)絡(luò)上有重復(fù)的 ip 地址。唯一可以使用 L2 模式的時(shí)間是集群上的單個(gè) POD。

最后，繼續(xù)運(yùn)行取決于 porter-manager，porter-manager 使用標(biāo)準(zhǔn)的 k8s POD 故障檢測(cè)機(jī)制，因此 porter-manager 可能需要大量的時(shí)間來重新啟動(dòng)，影響到新的和現(xiàn)有的服務(wù)，因?yàn)樗鼈儗]有 ARP 響應(yīng)。

BGP

Porter 使用 gobgp 實(shí)現(xiàn)了 BGP，但是它實(shí)現(xiàn)了 gobgp 功能的一個(gè)非常小的子集。Porter BGP 的實(shí)現(xiàn)只具有與本地網(wǎng)段的路由器對(duì)等的必要功能。

Porter 從 porter-manager 節(jié)點(diǎn)為集群建立單個(gè) BGP 對(duì)等體。BGP 對(duì)等體必須是在本地網(wǎng)段上，因?yàn)椴豢赡芘渲?BGP 多跳。

當(dāng)一個(gè)服務(wù)被定義時(shí)，porter-manager 會(huì)公布分配的地址，其下一跳是運(yùn)行容器的節(jié)點(diǎn)。擴(kuò)大部署，使 POD 分布在多個(gè)節(jié)點(diǎn)上，會(huì)導(dǎo)致為 ECMP 添加額外的路由。每個(gè)分配的地址都被轉(zhuǎn)換為一個(gè)主機(jī)路由（/32）。然而，這種流量策略行為是不正確的，下面將詳細(xì)介紹。

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

BGP 進(jìn)程作為 porter-manager 的一部分運(yùn)行，因此 porter manager 的故障會(huì)導(dǎo)致上游路由器的對(duì)等體宕機(jī)，軟件路由器將撤回它從 porter 學(xué)到的所有路由。

為了解決一個(gè)節(jié)點(diǎn)上有兩個(gè)路由器造成的問題，porter 用不同的端口號(hào)連接到上游的路由器。它解決了部分問題，必須注意手動(dòng)配置路由器 -ID，而不是通過使用主機(jī) IP 地址創(chuàng)建一個(gè)重復(fù)的路由器。

流量策略

在 Porter 中改變 externalTrafficPolicy:local 確實(shí)改變了其操作。Porter 總是將流量發(fā)送到有 POD 的節(jié)點(diǎn)或節(jié)點(diǎn)。這違反了 kubernetes 描述的行為。在 BGP 模式下，所有的服務(wù)都應(yīng)該被設(shè)置為 externalTafficPolicy:Local，因?yàn)檫@是 Porter 的行為方式，不管這個(gè)配置如何。這種設(shè)置將導(dǎo)致 kube-proxy 的正確配置，刪除一個(gè)不必要的 NAT 步驟，并保留源 IP 地址。波特的第二層操作有多個(gè) POD，導(dǎo)致重復(fù)的 IP 地址，因此進(jìn)一步討論這個(gè)設(shè)置如何影響現(xiàn)有的不正確的網(wǎng)絡(luò)行為是不相關(guān)的。

配置

配置是通過自定義資源，每個(gè) EIP 包含一個(gè)地址范圍和相關(guān)協(xié)議。

L2 不需要進(jìn)一步的配置，但是有兩個(gè) BGP 的 CR，BgpConf和 BgpPeer。BgpConf 要求定義RouterID，這進(jìn)一步強(qiáng)調(diào)了 BGP 的有限實(shí)施。按照慣例，這將是主機(jī)設(shè)備上的一個(gè)地址。然而，這將是混亂的，因?yàn)?Kubernetes 安排了這個(gè) POD，因此應(yīng)該使用另一個(gè)地址作為靜態(tài)標(biāo)識(shí)符。與大多數(shù)實(shí)現(xiàn)不同的是，Porter 沒有一個(gè)機(jī)制來自動(dòng)選擇一個(gè)有效的地址。

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

IPv6

Porter 沒有對(duì) IPv6 的支持。掃描代碼時(shí)沒有發(fā)現(xiàn)有任何 IPv6 支持。

總結(jié)

構(gòu)建這些負(fù)載平衡器協(xié)調(diào)器并不容易！K8s 網(wǎng)絡(luò)與主機(jī)和路由協(xié)議的結(jié)合需要大量的知識(shí)和技能。因此，我贊揚(yáng)開發(fā)者的工作。

引用鏈接

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

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

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