在自建 Kubernetes 叢集的過程中，負載平衡器的選擇一直是讓我花不少時間研究的議題。不像雲端環境有現成的 Load Balancer 服務可以直接用，地端（On-Premises）環境就得自己想辦法解決外部流量進入叢集的問題。今天就來聊聊我在實務上常碰到的兩個方案：MetalLB 和 Kube-VIP，分享一下我的觀察和心得。
MetalLB：裸金屬環境的老牌負載平衡方案
MetalLB 算是地端 Kubernetes 負載平衡領域的老面孔了，它為沒有外部負載平衡器的裸金屬環境提供了原生的 LoadBalancer Service 支援。
核心特色
| 特性 | 說明 |
|---|---|
| 運作模式 | 支援 Layer 2（ARP）與 BGP 兩種模式，L2 模式相容性高、設定簡單；BGP 模式則能實現更細緻的路由控制與流量分散 |
| IP 池管理 | 可自訂 IP 位址範圍，MetalLB 會從中分配外部 IP 給 LoadBalancer 類型的 Service |
| 部署方式 | 透過 ConfigMap 或 CRD 設定，安裝流程直覺好上手 |
| 架構組件 | Controller（叢集層級 IP 分配）+ Speaker（每個節點的 DaemonSet，負責 IP 廣播） |
適合場景
- 只需要為 Service 提供外部 IP 的基本負載平衡需求
- 網路環境單純、不需要太複雜路由設定的叢集
限制
無法直接為 Kubernetes API Server 做負載平衡，在 HA 架構下這可能是個問題。
Kube-VIP：輕量又全能的虛擬 IP 方案
Kube-VIP 是我後來越來越常使用的方案，它的定位是為 Kubernetes 提供虛擬 IP（VIP），同時涵蓋控制平面 HA 和 Service 負載平衡。
核心特色
| 特性 | 說明 |
|---|---|
| 統一部署 | 單一 DaemonSet 就能搞定，比起多組件部署更省資源也更好管理 |
| 控制平面 HA | 原生支援為 API Server 提供虛擬 IP，透過 Leader Election 機制實現高可用 |
| 負載平衡機制 | 使用 IPVS（IP Virtual Server）在 kernel space 做 Layer 4 round-robin，效能表現不錯 |
| 網路協定 | 同樣支援 ARP 和 BGP，ARP 適合同一 L2 網段，BGP 適合更複雜的拓撲 |
適合場景
- 需要控制平面高可用的叢集（這是它最擅長的）
- 希望用單一工具同時處理控制平面 VIP 和 Service Load Balancing
注意事項
如果同時搭配 MetalLB 使用，記得不要開啟 Kube-VIP 的 --services 參數，否則兩者會在 Service 負載平衡上打架。
兩者對比一覽
| 比較項目 | MetalLB | Kube-VIP |
|---|---|---|
| 主要用途 | Service LoadBalancer | 控制平面 HA + Service LB |
| 部署複雜度 | 中等（Controller + Speaker） | 低（單一 DaemonSet） |
| 控制平面 HA | 不支援 | 原生支援 |
| Layer 2 模式 | 支援 | 支援 |
| BGP 模式 | 支援 | 支援 |
| 負載平衡機制 | ARP/BGP 廣播 | IPVS kernel space |
| 資源消耗 | 較高 | 較低 |
| 與其他方案共存 | 良好 | 需注意 Service 模式衝突 |
我的選擇建議
根據我的經驗，這兩個方案其實不一定是二選一的關係：
- 只需要 Service LB：MetalLB 就夠用了，設定簡單、文件齊全、社群活躍
- 需要控制平面 HA：Kube-VIP 是首選，它原本就是為這個場景設計的
- 兩者都要：可以用 Kube-VIP 處理控制平面 VIP，MetalLB 負責 Service LB，這也是不少人採用的組合
最終選哪個，還是要看你的叢集規模、HA 需求和網路環境複雜度。建議在測試環境都跑一輪，實際感受一下各自的優缺點，再做決定會比較踏實。
發佈留言