作者：大飛哥，視源電子股份運維工程師， KubeSphere 社區用戶委員會廣州站站長，KubeSphere Ambassador，
公司介紹
廣州視源電子科技股份有限公司（以下簡稱視源股份）成立于 2005 年 12 月，旗下擁有多家業務子公司，截至 2022 年 12 月 31 日，公司總人數超 6000 人，約 60% 為技術人員，員工平均年齡約為 29 歲，
目前公司的主營業務為液晶顯示主控板卡和互動智能平板等顯控產品的設計、研發與銷售，產品已廣泛應用于家電領域、 教育資訊化領域、企業服務領域等，始終致力于通過產品創新、研發設計提升產品的用戶體驗，為客戶和用戶持續創造價值，公司自成立以來，依托在音視頻技術、信號處理、電源管理、人機互動、應用開發、系統集成等電子產品領域的軟硬體技識訓累，面向多應用場景進行技術創新和產品開發，通過產品和資源整合等能力在細分市場逐步取得領先地位，并建立了教育數字化工具及服務提供商希沃（seewo）、智慧協同平臺 MAXHUB 等多個業內知名品牌，
挑戰
隨著在 Kubernetes 上運行的應用程式數量增加，如何優雅地將服務匯出到集群成為一個需要解決的問題，Kubernetes 提供了 NodePort 和 Loadbalancer 來匯出服務，NodePort 受到主機埠數量的限制，過多的埠開放還會有安全風險，在流量治理方面更是讓人望而生畏；Loadbalancer 則用于宣告云供應商的服務，對于裸金屬服務器而言，Kubernetes 官方不提供支持，對于企業私有云中的 Kubernetes 集群，想要對外提供服務，就遇到了挺大的挑戰，在這種情況下，我們發現了 OpenELB, 它可以在 Loadbalancer 型別中匯出服務并穩定運行，
解決方案
作為 KubeSphere 團隊開源的專案，OpenELB（曾用名 Porter）是一款為裸金屬服務器提供 LoadBalancer 型別服務的產品，
總結起來，有如下幾個優點：
- 首先，它是由一個團隊而不是個人運行的，而且社區貢獻者頗多，因此可以避免廠商依賴或者無人維護，
- 其次，OpenELB 支持的協議比同類競爭對手更多，
- 最后，OpenELB 有完備的檔案，對中文支持友好，企業服務可以獲得更多的技術服務支持，在使用程序中，您會發現更多的驚喜，
實踐程序
管理員可以通過 NodePort 匯出 Kubernetes 服務，在這種情況下，每臺集群主機都會匯出同樣的埠，這在大規模集群中的開銷是巨大的，不幸的是，Kubernetes 可以使用的主機埠是有限的（30000-32768），開源社區建議使用動態埠，這可能會帶來風險和管理難度，給流量治理帶來巨大的挑戰，Kubernetes 中的默認 LoadBalancer 型別的服務僅支持云廠商提供的服務，
OpenELB 是一種解決方案，用于為裸機提供負載均衡型別的服務，基于 BGP 和 ECMP 協議，可實作最佳性能和高可用性，OpenELB 提供了兩個功能模塊：
-
負載均衡控制器（Controller）
該控制器負責將 BGP 路由同步到物理交換機，
-
CRD 和 CRD 控制器
CRD EIP 定義了在 Layer2 模式中使用的 EIP 地址池，同樣，CRD BgpConf 和 BgpPeer 定義了 Kubernetes 集群內部的 BGP，并用于 BGP 模式，
生產環境中，強烈建議使用 BGP 模式，如下圖所示，把物理路由器設備劃歸到 AS50001 中，把 OpenELB 所在的集群劃歸到 AS 50000 中，OpenELB 會建立服務路由規則，并將其同步到物理路由器上，BGP 路由器根據負載均衡策略轉發對應的流量到達相應的集群主機節點上，kube-proxy 再近一步轉發流量到 Service 層，BGP 模式需要物理路由器設備和集群主機網路的支持，其最大的優點就是穩定可靠，解決了路由轉發的單點故障問題，
雖然 BGP 模式是建議的模式，但是在實際應用中，Layer2 模式使用更為廣泛，因為它簡單易用，配置要求低，配置簡單，對于使用虛擬機作為 K8s 集群節點的用戶，受 VMware 網路的限制，只能選擇 Layer2 模式，讓我們來看下 Layer2 模式的網路架構，
我們使用 GitLab CI 和 Argo CD 建立自動化流水線，以幫助開發人員提高效率，并使用 Nginx Ingress 處理 7 層請求，Argo CD 使用 IP 10.10.1.2 匯出負載均衡型別的服務，而 Nginx Ingress 則使用 IP 10.10.1.3 匯出，因此，我們可以建立如下的 DNS 記錄：
# HOSTS
10.10.1.2 argocd.cvte.com
10.10.1.3 ingress.cvte.com
當用戶訪問像 argocd.cvte.com 這樣的域名時，請求將路由到路由器，由于 EIP 不能系結到任何網路卡硬體上，因此路由器需要廣播 ARP 請求，這個請求將被 OpenELB 回應一個集群節點的 IP，這樣，路由器就知道將網路資料包發送到哪里了，由 Ingress 控制的任何其他域都會路由到另一個 EIP，
通常情況下，OpenELB 僅會使用一個集群節點 IP 回應 ARP 請求，如果此節點關倍訓不可用，則 OpenELB 會切換到另一個節點，以確保業務的連續性，
通過對 Layer2 模式原理的講解，不難發現，Layer2 模式有單點故障風險，為了減少這種單點風險，KubeSphere 研發團隊貼心地開發了 VIP 模式，即虛擬 IP 模式，VIP 提供了單點故障的轉移，當 Layer2 模式中的主機節點故障，OpenELB 會自動切換流量到備份 IP，VIP 模式，只能算是減少單點故障風險，無法完全消滅風險，所以在生產環境中，普通 Layer2 模式或 VIP 模式，都不建議使用，根據我們的經驗，如萬般無奈，只能使用 Layer2 模式，那就獨立兩臺機器，只用來接收外部流量，并盡量保證這兩臺機器的高可用，
使用效果
OpenELB 以 TCP 協議匯出服務，并與 Ingress 配合使用，可以輕松管理大多數 Web 應用程式，與 NodePort 不同，OpenELB 只需要幾個 EIP 即可代理請求到服務，流量集中處理從而極大地降低了管理難度，
總結
OpenELB 提供了一種為裸金屬服務器匯出 LoadBalancer 型別服務的功能，幫助我們輕松地管理網路基礎設施，作為 KubeSphere 的一個子專案，OpenELB 非常適合在企業私有云環境中使用，具有較強的穩定性和可信度，
參考閱讀
-
負載均衡器 OpenELB ARP 欺騙技術決議
-
詳解 K8s 服務暴露機制與 OpenELB 負載均衡器插件（直播回放 + PPT）
本文由博客一文多發平臺 OpenWrite 發布！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/554786.html
標籤：其他
上一篇：華為云 UCS GitOps：輕松交付多集群云原生應用
下一篇：返回列表