iT邦幫忙

第 11 屆 iThome 鐵人賽

DAY 13
0
DevOps

其實我真的沒想過要利用研替剩餘的 30 天分享那些年 On-premise Container & Kubernetes 經驗系列 第 13

[Day13] 實作 Kubernetes 裸機 Load Balancer Part3

今天因為忙 Meetup 到太晚,回家處理一些事情就 11 點了... 只好先寫這樣,明天再補充完整內容。

前言

在公有雲環境中,負載平衡器建立與外部 IP 位址分配都能由雲平台完成,且 Kubernetes 也能輕易地用 Cloud Provider 來進行整合。但在地端(或裸機)環境中,原生 Kubernetes 就無法達到這樣功能,必須額外開發系統才能達到目的。而慶幸的是前 Google 工程師也看到這樣問題,因此開發了 MetalLB 來協助非雲平台 Kubernetes 能實現網路負載平衡的提供。且 MetalLB 以 Kubernetes 原生方式,直接在 Kubernetes Service 描述LoadBalancer 類型來要求分配負載平衡器 IP 位址。雖然 MetalLB 確實帶來了好處,但它使用起來沒問題嗎?另外它究竟是怎麼實作的?會不會影響目前叢集網路環境呢?

基於這些問題,今天想透過深入了解 MetalLB 功能與實作原理,以確保發生問題時,能夠快速解決。

架構

MetalLB 是基於標準路由協定實作的 Kubernetes 叢集負載平衡專案。該專案主要以兩個元件實現裸機負載平衡功能,分別為:

  • Controller:是叢集內的 MetalLB 控制器,主要負責分配 IP 給 Kubernetes Service 資源。該元件會監聽 Kubernetes Service 資源的事件,一但叢集有 LoadBalancer 類型的 Service 被新增時,就依據內容從一個 IP 位址池分配負載平衡 IP 給 Service 使用。
  • Speaker:利用網路協定(L2: ARP/NDP, L3: BGP)告知負載平衡 IP 的目的位址在何處,並且如何路由。Speaker 是一個被安裝在所有節點上的 Controller,而這些叢集上的 Speaker 只會有一個負責處理事情。

待補架構圖跟程式細節。

在 MetalLB 中,實現了 L2(ARP/NDP) 與 L3(BGP) 的模式,使用者可以透過在 MetalLB 組態檔設定。而這種模式差異在哪邊呢?

Layer 2

在 L2 模式下,MetalLB Speaker 會在叢集中,選出一個節點以標準地址發現協定(IPv4 用 ARP、IPv6 用 NDP)讓已分配的負載平衡 IP,透過 ARP/NDP 讓本地網路能夠得知目的位址。

待補架構、流程圖跟程式細節說明。

這種模式好處在於簡單,且不需要外部硬體或配置。但受限於 L2 網路協定。

BGP

在這種模式下,叢集節點的 MetalLB Speaker 會與外部路由器建立 BGP 對等互連,並告訴路由器如何將流量轉發到Service IP,然後藉由 BGP 策略機制,在多個節點之間實現負載平衡,以及細粒度的流量控制。

待補架構、流程圖與程式細節說明。

這種模式適合生產環境,但需要更多的外部硬體與配置來達成。但要確保實作 BGP 的 CNI 不會衝突。

結語

從了解 MetalLB 原理後,可以更清楚知道一個 Kubernetes 裸機負載平衡該如何實現。但是除了 MetalLB 以外,還有其他方法可以實現嗎?當然有!大家可以參考我之前在社群分享的投影片 How to impletement Kubernetes Bare metal Load Balancer

Reference


上一篇
[Day12] 實作 Kubernetes 裸機 Load Balancer Part2
下一篇
[Day14] 實作 Kubernetes 外部認證系統整合: 以 LDAP 為例
系列文
其實我真的沒想過要利用研替剩餘的 30 天分享那些年 On-premise Container & Kubernetes 經驗30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言