負載均衡設備哪家好？最好是能適用於金融業的

　　在金融行業的傳統IT基礎架構中，專有硬件負載均衡設備（如F五、Radware等）廣泛具有功能強、性能高、運行穩定等特色，成爲解決應用系統對外提供統一服務的首選方案。近年來，隨着OpenStack、Kubernetes等雲技術的興起，應用系統的微服務化、快速迭代對資源的彈性伸縮能力提出了更高的要求，這就要求負載均衡有更好的靈活性和開放性。開源負載均衡軟件因其開放的設計，完善的API接口以及對應用靈活部署需求的知足，在金融行業的雲環境中逐步推廣使用。民生銀行在Kubernetes容器平臺建設中，探索使用了一種靈活的軟件F5解決方案，在利用F5傳統優點的同時，也知足了容器應用的高靈活性要求。

　　Kubernetes服務發佈方式及侷限性

　　Service是Kubernetes最核心的資源對象之一，經過它能夠爲一組具有相同功能的容器應用提供一個統一的訪問入口地址，並將請求負載分發到後端的各個容器應用上。這一點與傳統IT基礎架構中F5等負載均衡設備將訪問請求負載分發到後端功能相同的應用上相似，Kubernetes集羣中每一個節點上運行的kube-proxy其實就是一個智能的軟件負載均衡器，它負責把對Service的請求轉發到後端的某個pod實例上，並在內部實現服務的負載均衡與會話保持機制。Service被分配了一個全局惟一的虛擬IP地址，稱爲ClusterIP。但ClusterIP只能實現集羣內部的訪問（即東西向服務），對於須要經過外部IP對外提供訪問（即南北向服務）的場景，Kubernetes提供了三種主要方案，分別是NodePort 、LoadBalancer 、Ingress。       

　　1 NodePort

　　NodePort 的實現方式是在每一個節點上爲須要外部訪問的Service開啓一個對應的TCP監聽端口，外部系統用<NodeIP>:<NodePort>能夠從集羣外部訪問一個NodePort服務，NodePort 服務會路由到 ClusterIP ，經過kube-proxy轉發至後端的容器，完成對服務的訪問。NodePort的方式是解決服務暴露問題最直接的作法，其配置和維護都很簡單，但它依賴於kube-proxy，目前僅支持輪詢算法以及源地址會話保持。在負載均衡的其餘特性方面還有必定缺陷。另外，NodePort佔用node節點一個獨立的端口，限制了集羣中暴露服務的數量。且在實際使用過程當中定義一個NodePort，須要在Kubernetes集羣中的全部節點上開通此端口的入訪能力，所以通常會結合集羣外的負載均衡設備，與kube-proxy造成兩級負載均衡的架構，對性能會產生必定影響，同時增長成本。

　　2 LoadBalancer 

　　LoadBalancer 是Kubernetes深度結合雲平臺的一個組件，使用它構建服務時，其實是向底層IaaS申請建立一個負載均衡來實現。IaaS網絡和容器網絡在不一樣雲平臺的融合方案不一樣，所以LoadBalancer 和雲平臺的網絡方案深度耦合，只能在特定的雲平臺上使用，侷限性較大。

　　3 Ingress

　　Ingress能夠很好的解決LoadBalancer和NodePort的限制。它由3個組件組成：Ingress策略集、Ingress Controller和反向代理負載均衡器（如Nginx）。Ingress策略集定義了集羣外的流量到達集羣內的Service的規則。Ingress Controller與Kubernetes的API交互，實時感知後端Service、pod的變化，再結合Ingress策略集生成配置，而後更新反向代理負載均衡器的配置，實現動態服務發現與更新。反向代理負載均衡器對集羣外流量進行負載分發。現有的Kubernetes版本已將Nginx與Ingress Controller合併爲一個組件Nginx-Ingress-Controller，無需單獨部署Nginx。但Kubernetes原生Ingress是一個七層負載均衡技術，僅適用於http服務。另外，其並未解決Kubernetes環境下，不一樣租戶的服務隔離問題。

　　F5容器服務發佈方案及實踐

　　隨着容器技術的發展，在應用容器化、微服務化的趨勢下，F5公司基於多年在負載均衡領域的經驗推出了Kubernetes容器服務解決方案，既兼顧了容器環境下應用隨時可能啓停、遷移等靈活性要求，又具有傳統F5穩定、安全、高性能等特性。

　　F5容器服務解決方案實現了容器的南北向服務更加靈活的發佈能力。相對於開源方案具有如下優點。

　　簡化的架構：目前開源方案中，在業務量增大後，須要在容器外部再部署負載均衡設備來實現node級的擴展，而F5的方案只須要經過一組設備就能夠實現pod或node級的擴展，簡化結構，方便使用。

　　普遍的應用場景：目前開源方案只能支持七層應用的分發對用戶的使用場景有所限制；F5的方案能夠支持4、七層方案，能夠知足用戶絕大部分的使用場景。

　　靈活的發佈能力：開源方案使用node的IP地址進行發佈，發佈場景受到很大限制；F5方案中VS（VirtualServer）地址可使用用戶規劃的任意網絡地址進行發佈，實現靈活部署的須要。

　　加強的應用交付能力：開源方案在應用交付的算法、健康檢查等都比較簡單；F5方案中提供了19種負載均衡算法、38種健康檢查、11中會話保持方法，豐富的方法方便用戶各類應用的靈活配置。

　　監控能力：開源方案實現了基本分發功能，但監控能力很弱，對數據流以及業務的監控頗有限。F5方案中，能夠經過自己的HSL功能實現最高每秒20萬日誌的發送，同時能夠配合requestlog或irules方式能夠讀取到全部應用層數據，方案網絡故障排除及系統層分析，爲大數據平臺提供數據支撐。
　　安全防禦能力：F5自己提供了大量的安全功能，包括SSL、訪問控制、應用防禦等。開源方案只提供了基本的應用分發功能，沒有安全功能擴展。

　　該解決方案包含2個組件，VE（Virtual Edition）和CC（Container Connector）。VE是F5LTM的軟件化商業產品，能夠安裝在虛擬機或者物理機上，其功能與硬件設備徹底一致。CC是F5解決方案的一個關鍵組件，爲用戶提供了企業級支撐，同時也是開源產品，用戶能夠根據本身的須要對CC進行功能擴展。它以容器的形式部署在Kubernetes集羣中，經過讀取Kubernetes API獲取集羣內的服務資源並將其轉化爲VE上的配置。管理員能夠爲每個租戶部署一組CC，每組CC獨立控制VE上的一個對象配置隔離區域（partition），該partition下的資源徹底由該組CC獨立控制。該方案中，負載均衡策略的定義能夠由多種方式實現，可使用Ingress，也可使用ConfigMap。
　　

　　民生銀行通過前期技術預研，選擇F5 CC+VE方案，利用CC與Kubernetes進行API交互，實現與容器平臺的聯動，知足容器應用的靈活性需求；配置上採用ConfigMap進行負載均衡策略下發，實如今Kubernetes層面進行F5策略配置工做；網絡架構上採用VE直接對集羣中的pod進行負載分發，減小網絡層次，提高負載均衡性能；同時，經過將Kubernetes的namespace與VE的partition映射，實現不一樣容器租戶負載均衡資源的隔離。

　　1網絡部署方案

　　目前，民生銀行Kubernetes環境採用的是Flannel VXLAN網絡模型，容器網絡由Flannel負責分配與管理，不一樣節點上的容器間互訪由Flannel自動化管理各個節點上的路由表、ARP表及FDB表。本方案中，F5 VE是以虛擬Kubernetes node節點加入到集羣，須要配置VXLAN網絡信息，這些網絡信息會被Flannel同步到各個節點。同時，CC從Flannel得到其它容器的網絡信息後傳遞給VE，VE上生成相應的表項後，實現與容器之間直接通訊。
　　

　　2 服務發佈方案
　　在服務發佈上，經過部署YAML文件方式進行發佈，操做均在Kubernetes管理平臺上進行，可採起的形式以下：

　　基於VE資源屬性的ConfigMap方式進行發佈，此發佈模式下，根據VE定義的ConfigMap資源屬性進行發佈，VSIP，健康檢查，負載均衡算法等均在該ConfigMap中定義。ConfigMap方式支持如下類型的發佈：

　　   o 像傳統F5部署同樣部署全部高級應用交付特性（iApp）
　　   o 發佈L4類型業務
　　   o 發佈L7類型業務
　　   o 應用WAF安全特性

　　基於Ingress的發佈，實現基於L7策略的發佈。

　　發佈UnattachedPool，此場景主要用於有自動化分配VS地址需求的場景。

　　同時，對於上述網絡模型下，也支持經過VE FQDN技術實現headless服務的自動化發現，經過在Kubernetes內發佈標準的headless服務，允許VE訪問Kubernetes內置的DNS服務，便可實現經過域名自動化發現相關endpoints到VE中，實現更加靈活的自定義發佈：

　

　　3 資源隔離方案
　　在Kubernetes內不一樣的namespace（如下簡稱NS）隔離不一樣的資源對象時，管理員爲每一個NS建立一組 CC，監視NS內的資源對象，並將其發佈到同一個VE的不一樣partition上或者不一樣的VE上，以達到資源隔離的目的。
　

　　對於業務訪問量相對較小的環境，能夠選擇複用VE，不一樣NS對應不一樣的partition，提升資源的利用效率。隨着業務規模的擴大，能夠採用不一樣NS對應不一樣的VE的方案進行擴容。

　　實際應用效果與收益

　　本節以某項目爲例，介紹本方案在落地場景中探索使用的應用效果和收益。該項目爲典型三層架構體系，在Web區和App區均部署了高可用的F5 VE用於服務發佈。實施效果與收益以下：

　　1 實現F5設備動態感知容器服務能力

　　經過部署在Kubernetes租戶內的F5 CC動態感知容器服務的變化，解析服務建立以及銷燬事件，動態更新F5 VE設備，實現服務自動發現，動態感知能力。以此來支持應用彈性伸縮能力。
　　

　　2 實現F5到pod的負載轉發能力

　　經過F5 VE和Kubernetes集羣創建的VXLAN網絡，實現了VE服務直接訪問pod的能力，以下圖：
　

　　經過實現以上功能，減小了NodePort的服務器端口獨佔以及端口不足的問題，同時減小了NodePort方式下對kube-proxy的依賴。

　　3 實現負載均衡多租戶能力

　　在F5 VE方案中經過僞host定義、CC定義、F5 VE下發策略等配置明肯定義了F5 VE租戶（partition）和Kubernetes租戶（namespace）之間的一對一關係，實現了F5 VE和Kubernetes的多租戶聯動支持能力。爲F5 VE設備在容器環境下租戶化運營提供了基礎。

　　以下圖所示，在實際應用場景下，Kubernetes租戶是scfp，F5 VE partition是scfp_partition。

　

　　全部Kubernetes的scfp租戶下發布的服務，對應在F5 VE上的轉發策略，僅在scfp_partition下可見。

　　4 實現F5設備在容器環境下的自服務能力

　　F5 VE在實現租戶安全的前提下，實現了經過Kubernetes原生語義ConfigMap定義F5 VE負載均衡策略，經過Kubernetes的命令行實現F5設備規則的配置管理能力，實現了在租戶內F5資源的自服務能力。

　　5 豐富容器環境下負載均衡算法

　　經過引入F5，豐富了容器環境中的負載均衡算法。在ConfigMap中的balance字段能夠實現負載均衡轉發算法的選擇，默認是round-robin，除此以外還有18種算法。在實際應用中，咱們採用的是least-connections-member算法，以下圖所示：
　　

　　綜上所述，咱們對Kubernetes的容器管理能力和F5的負載轉發能力進行強強聯合，在實際應用中充分利用F5 VE、F5 CC在應用系統交付、配置自動化、應用系統彈性伸縮等方面的特性，取得了顯著效果。