今天跟大家分享在地端資料中心內建立Kubernetes叢集之後，如何針對網路進行更進一步的優化。除了CNI（容器網路接口）的設定，實務上我還會再另行建立Loadbalancer的機制。
至於為什麼要這樣做呢，就在這篇文章中透過對MetalLB的功能說明，相信您也可以理解為什麼這樣做在實務上是較好的做法之一。
網路流量進來後，如何平均分配
- MetalLB是什麼？
- L2模式的運作流程
- L2模式的運作模式
- 結論
1.MetalLB是什麼?
官網說明：
Provides a network load-balancer implementation. In short,it allows you to create Kubernetes services of type LoadBalancer
in clusters that don’t run on a cloud provider, and thus cannot simply hook
into paid products to provide load balancers.
提供在地端實現網絡負載均衡器的方式。簡而言之，
它允許您在非運行雲端提供商上的叢集中創建類型為LoadBalancer的Kubernetes的服務。
因為地端的K8S原生並沒有實作LoadBalancer的功能，所以只能在公有雲IaaS平台才能直接使用LoadBalancer類型的service。除此之外就只能用NodePort or externalIP來暴露服務。但一般來說建議還是使用LoadBalancer類型較好。
以下幾點說明使用MetalLB的優點：
- 簡單設定：簡化了負載均衡器的配置過程，使其易於設置和管理。它不需要太多的複雜配置，並提供了一個簡單的方式來將外部IP地址分配給Kubernetes服務。
- 無雲端依賴：對於那些不使用雲端提供的負載均衡服務的用戶來說，MetalLB是一個理想的解決方案。它可以在本地資料中心或私有雲中運作，無需依賴雲端供應商的特定產品或服務。
- 節省成本：使用MetalLB可以節省成本，因為它不需要訂閱付費的雲端負載均衡器服務。這對於預算有限的組織或個人來說尤其有吸引力。
- 可擴展性：MetalLB可以根據需求擴展，並處理不同類型的負載均衡需求。它能夠動態地調整IP地址的分配，以應對流量增長，因此非常適用於具有變化需求的環境。
- 與Kubernetes整合：MetalLB與Kubernetes緊密整合，允許您使用Kubernetes服務類型LoadBalancer，使其與其他Kubernetes元件無縫協作。這樣可以實現更高的自動化和自我修復性。
2.L2模式的運作流程
運作流程 (From: http://timd.cn/k8s/metallb/)
當外部想要找K8S內的某個服務，透過發送ARP，由Leader節點用MAC address回應。外部主機就會將回應存在本地的ARP table，下次就可以直接從本地取得。當請求已到達節點之後，節點就會再透過kube-proxy將請求轉到負載平衡的目標Pod。
(注意：此處在節點內還是用kube-proxy來提供服務的負載平衡)
(1) 主要任務：
- Task 1 — IP 位址分配 : 當建立LoadBalancer類型時，MetalLB自動從預先定義的IP Pool中分配IP位址出來，刪除Service之後，IP就會歸還Pool。
- Task 2 — 對外廣播：配好IP後，還要讓Cluster外的網路知道這個位址的存在。
L2模式下，IPv4使用ARP ; IPv6使用NDP。
=> ARP: 從IP取得MAC的TCP/IP protocol
=> NDP: 取代ARP, ICMP，用來跟踪鄰居狀態、重復地址檢測、路由器發現、重導向
(2) 組成元件：
- Controller : 以deployment的方式實現，用來監聽Service的變動、分配/回收IP。
- Speaker : 用來實現對外廣播，以daemonset方式實現，對外廣播Service IP。
(3) 元件的工作任務：
- Step1. Controller監聽Service的變動、分配/回收IP，監聽到Service設定為Loadbalancer模式時，就從IP Pool分配一個對應的IP，並且在刪除Service時(或改成其他模式)回收IP
- Step2. Speaker根據選擇的Protocol進行對應的廣播與回應，當流量透過TCP/UDP到達指定的Node時，由Node上的Kube-Proxy元件處理流量，分發到對應的Pod。
3.L2模式的運作模式
這裡簡單說明一下這個模式下是怎麼運行，以及L2模式的缺點。
L2 Speaker是DaemonSet，故在每個節點都會有一個Pod。幾個Pod間會自我投票選出Leader。而Leader speaker大致上是用以下方式選擇出來：
選出一個Leader，由它來回應請求
- 選舉機制：預設情況下，Speaker 通過 API 服務（例如 Kubernetes API Server）來進行選舉。Speaker 會向 API 服務發送Lock的請求，並獲得競選 Leader Speaker 的權利。
- 選舉結果：當 Speaker 發送選舉請求後，API 服務會選擇其中一個 Speaker 作為 Leader Speaker，並通過 API 服務的回應通知其他 Speaker 誰是 Leader Speaker。Leader Speaker 將在 API 服務中註冊一個具有特殊標識的 ConfigMap，以表明它是 Leader Speaker。
3. Leader Speaker 負責 ARP 代理：一旦 Leader Speaker 被選出，它將成為 ARP 代理的主要負責者。只有 Leader Speaker 會回應外部設備發送的 ARP 請求，這有助於確保在集群中只有一個 Speaker 負責處理 ARP 請求。
- 失效處理：如果 Leader Speaker 在某些情況下變得不可用，例如由於故障或網絡問題，則選舉機制將再次觸發，以選擇一個新的 Leader Speaker，以確保系統的可用性。
#-----------------------------------------------
# S3-1. 每個node都有一個speaker
#-----------------------------------------------
[lb01]# kubectl get pod -o wide
說明：Leader Pod會取得所有LB類型的Service，將已分配的IP綁到目前主機網卡上。
Leader也會回應對External IP的ARP/NDP請求。因此Speaker所在的機器會有多個IP。
#-----------------------------------------------
# S3-2. 確認ARP MAC
#-----------------------------------------------
[lb01]# kubectl get pod -o wide
[lb01]# kubectl get svc
[lb01]# arp 10.107.88.90
以上說明LoadBalance IP的MAC與worker02的MAC相同，也就是說Pod是運行在worker02之上，所以當Request發起時，會由worker02上的speaker來回應，流量就會導至worker02節點。
在節點內，kube-proxy會將收到的流量傳播到對應Service後端的Pod。在這個層面上，L2模式其實並沒有真的實作Loadbalance，而是實作了一個failover機制，當Leader節點出問題時，可以自動接管服務。
※ L2模式的缺點：
- 單節點局限：因為會選某一個節點上的Pod成為Leader Pod，故所有的頻寬會被這個節點的頻寬限制住。L2比較像是故障轉移，而非負載均衡，因為同一時間只能在某一台節點負責接收資料。
- 故障轉移慢：可實現
自動故障轉移，目前是透過memberlist，當其他節點檢測到Leader故障後會自選出新的Leader。新的Leader會自動接管所有External IP並發送大量的L2封包來通知客戶端(其他節點)ExternalIP的MAC. (官網說通常10秒內會轉完)
4.結論
MetalLB 主要分為 Controller 和 Speaker二個部分，Controller 負責IPAM，Speaker 則負責 IP 通告。這二個元件就可以實現MetalLB的全部功能了。有二種模式可依實際環境配合使用：
- L2模式：(通用、容易使用，沒有限制、但局限性大)
=> 優點：通用性好，適合任何網路環境，不需要特殊硬體
=> 缺點：單節點瓶頸和故障轉移慢
- BGP模式：
=> 優點：可以在多節點間負載平衡、沒有單節點瓶頸、故障轉移快
=> 缺點：使用BGP就需要支援硬體路由器設備
※ 建議：
- BGP是比較理想的實作。L2模式是基礎實現，完整功能建議還是要使用BGP模式。
- 能用BGP就用BGP，不知道要用什麼模式就先用L2模式
本篇先針對MetalLB的基本概念先進行說明，接下來會分享如何在Kubernetes Cluster上進行MetalLB的部署工作，敬請期待後續，也感謝您的觀看，下期再見!!!
References:
