民生銀行：基於 F5 技術實現 Kubernetes 生產環境最佳實踐

1 前言

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

2 Kubernetes服務發佈方式及侷限性

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

2.1 NodePort

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

2.2 LoadBalancer

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

2.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環境下，不同租戶的服務隔離問題。

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

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

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

1. 簡化的架構：目前開源方案中，在業務量增大後，需要在容器外部再部署負載均衡設備來實現node級的擴展，而F5的方案只需要通過一組設備就可以實現pod或node級的擴展，簡化結構，方便使用。
2. 廣泛的應用場景：目前開源方案只能支持七層應用的分發對用戶的使用場景有所限制；F5的方案可以支持四、七層方案，可以滿足用戶絕大部分的使用場景。
3. 靈活的發佈能力：開源方案使用node的IP地址進行發佈，發佈場景受到很大限制；F5方案中VS（VirtualServer）地址可以使用用戶規劃的任意網絡地址進行發佈，實現靈活部署的需要。
4. 增強的應用交付能力：開源方案在應用交付的算法、健康檢查等都比較簡單；F5方案中提供了19種負載均衡算法、38種健康檢查、11中會話保持方法，豐富的方法方便用戶各種應用的靈活配置。
5. 監控能力：開源方案實現了基本分發功能，但監控能力很弱，對數據流以及業務的監控很有限。F5方案中，可以通過本身的HSL功能實現最高每秒20萬日誌的發送，同時可以配合requestlog或irules方式可以讀取到所有應用層數據，方案網絡故障排除及系統層分析，爲大數據平臺提供數據支撐。
6. 安全防護能力：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。

圖1 組件調用關係

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

3.1網絡部署方案

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

圖2 網絡部署圖

3.2 服務發佈方案

在服務發佈上，通過部署YAML文件方式進行發佈，操作均在Kubernetes管理平臺上進行，可採取的形式如下：

• 基於VE資源屬性的ConfigMap方式進行發佈，此發佈模式下，根據VE定義的ConfigMap資源屬性進行發佈，VSIP，健康檢查，負載均衡算法等均在該ConfigMap中定義。ConfigMap方式支持以下類型的發佈：
  • 像傳統F5部署一樣部署所有高級應用交付特性（iApp）
  • 發佈L4類型業務
  • 發佈L7類型業務
  • 應用WAF安全特性
• 基於Ingress的發佈，實現基於L7策略的發佈。
• 發佈UnattachedPool，此場景主要用於有自動化分配VS地址需求的場景。

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

圖3 F5 VE FQDN配置

3.3 資源隔離方案

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

圖4 k8s namespace和F5 partition關係

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

4 實際應用效果與收益

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

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

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

初始狀態：

彈性伸縮（增加replicas數量）：

kubectl scale --replicas=3 deployment/nginx-server -n scfp

擴容後狀態：

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

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

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

4.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.4 實現F5設備在容器環境下的自服務能力

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

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

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

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

5 總結

本文我們對Kubernetes服務發佈能力以及F5提供的VE+CC服務發佈能力進行介紹及比較分析，並對F5 VE+CC方案的效果及收益進行詳盡闡述。

後續我們將依託F5 VE+CC自身具備的數據深度挖掘能力，在容器業務級探測、容器應用性能監控、容器應用數據可視化等方面進行更多的探索和分享。另外，F5 VE+CC作爲雲服務能力，我們會在後續工作中逐步完善，更好的以租戶化、服務化的方式滿足應用彈性伸縮、藍綠髮布、灰度發佈等需求。

作者信息

• 李高：任職民生銀行網絡管理中心，負責數據中心網絡規劃、建設及相關運維工作。現主要負責民生銀行雲環境下SDN網絡的技術研究及整體規劃建設工作。
• 張壽元：任職民生銀行雲技術管理中心，高級工程師，負責行內雲平臺建設、落地工作，之前負責行內中間件系統運維工作，超過十五年的IT經驗，熟悉軟件開發，運維管理等。
• 王全：任職民生銀行網絡管理中心，負責行內數據中心網絡規劃、建設、運維等工作，在應用交付/負載均衡技術領域具有十年以上的研究及實踐經驗。目前在雲計算、SDN網絡環境下的自動化運維、應用數據智能分析方面進行積極的探索和實踐。
• 盧宇亮：任職民生銀行雲技術管理中心，負責雲平臺研發和推廣工作。畢業於北京理工大學，先後從事DevOps、雲計算、微服務領域的產品研發和技術研究工作。
• 劉婉輝：任職民生銀行雲技術管理中心，負責行內雲平臺落地、推廣等工作，目前致力於容器及容器編排技術研究以及雲平臺運維管理等。