如何構建高可用、高併發、高效能的雲原生容器網路？

談起雲原生基礎設施構建，就必然會提到雲原生的容器網路。

眾所周知，容器網路作為雲原生的基石，是雲原生平臺必不可少的基礎元件，也是雲原生容器平臺構建時的最大挑戰之一。

隨著銀行應用數量和型別的進一步增多，對網路複雜度的要求也越來越高。銀行的應用有自身特點，銀行應用的管理級別不同，訪問特色也不同，需要考慮如何相容傳統網路架構，實現傳統網路和容器網路之間的互聯互通，同時，傳統應用容器化遷移後如何實現固定IP，以及對於容器多網路平面、多網路卡的管理，多租戶和跨雲網路、容器流量的監測、排程與QoS等也都面臨新的挑戰。

目前有很多銀行容器網路的內部其實是一個“黑盒”，容器內部和外部的網路沒有打通，也無法實現跨雲多網路叢集的互通，亟需進行轉型改造。

在這種壓力下，構建高效能的容器網路就顯得尤為重要，然而：

兩地三中心架構中的容器網路怎麼改造可用性更高?

高併發場景下，銀行的容器網路如何規劃?

如何打造高效能的容器網路?

本篇文章將為你解答。

兩地三中心架構中的容器網路怎麼改造可用性更高?

面對應用的高可用性需求，很多銀行都在積極建設兩地三中心，或者異地災備建設。那麼如何對接或改造容器平臺的網路，以滿足容器平臺中應用與傳統虛擬機器、物理機中舊業務系統的相互通訊，避免或儘可能減少對銀行現有網路管理模式的衝擊呢?

首先從整體來看，兩地三中心架構下的容器網路改造，需要依據容器平臺所依賴的IaaS能力而定。譬如容器平臺部署在傳統虛擬化平臺，也沒有啟用SDN網路，如果容器網路設計為hostnetwork模式，則容器POD的應用和傳統虛擬機器、物理機的舊業務系統是直接可以通訊的。

如果容器平臺的宿主節點在用IaaS的虛擬機器，且啟用了SDN網路，容器平臺啟用的CNI特性，則容器POD的應用可以和IaaS虛擬機器的業務應用直接通訊。如果和傳統網路中的舊應用通訊，則需要開啟IaaS的NAT特性或者為宿主節點配置EIP地址。

銀行容器平臺中的容器應用與傳統虛擬機器、物理機中舊業務系統的相互通訊遇到最多的問題都集中在IP有狀態這件事情上，因為傳統容器平臺上應用如果要實現對外通訊，主要有兩種方式：一種是基於宿主機IP+埠，另外一種是基於域名，這兩種應用的對外暴露模式都隱藏了容器平臺上應用的真實IP資訊，所以不僅會造成傳統虛擬機器、物理機中舊業務系統無法和容器平臺中應用的IP扁平化訪問的問題，同時也讓銀行現有網路管理模式無法對於容器平臺上的應用進行IP定位和網路資源管理。

針對以上問題，銀行在兩地三中心架構中可以採用Kube-OVN Underlay網路解決方案對接或改造容器平臺網路，Kube-OVN underlay網路解決方案透過採用OpenStack的ovs二層虛擬交換技術，將容器平臺上的應用和傳統虛擬機器、物理機中舊業務系統拉平到一個二層網路平面，讓容器平臺上的容器應用和傳統虛擬機器、物理機一樣的使用底層網路資源並實現IP直達通訊。這樣可以使銀行現有的網路管理模式在Kube-OVN的underlay容器網路下依然有效。

高併發場景下，銀行的容器網路如何規劃?

在高併發場景下，銀行傳統的網路架構相對缺少靈活性，已無法滿足日益增長的敏態業務需求。採用容器後，容器網路如何相容傳統網路和安全管理，並提供擴充套件的靈活性，是每一個銀行使用者都在關注的問題。

我們在金融行業的大量實踐中發現，雲原生的平臺化思維和傳統IT的條線式思維存在著一定矛盾。雲原生希望透過一個yaml檔案描述應用，所有的部署工藝、應用的計算、儲存、網路應該能夠自動化生成，而銀行專門的網路部門都有嚴格定義的網路規範，它們之間的矛盾在銀行業是特別突出的。

從實際落地的角度來看，可以採取以下幾點建議來有針對性地解決這個矛盾，合理規劃銀行的容器網路。

首先，在技術思路方面，建議underlay和overlay同時進行。目前容器網路兩個基本技術思路是overlay和underlay，overlay是建設虛擬網路，容器採用虛擬IP;underlay是複用下層物理網路，容器像虛擬機器一樣使用下層網路。從某種意義上說，overlay是平臺化思維的產物，underlay是條線式管理思維的產物。某些銀行可以允許大規模overlay，個別場景採用underlay(例如多播、運管功能等)，這樣兩個一起搞，同時兼顧。另外還有些銀行目前基本沒有overlay的空間，更多采用underlay管理;而還有些銀行在虛擬化上建設容器平臺，underlay不能用(underlay可能會和IaaS網路有衝突)，導致只能用overlay。鑑於這些情況，我的建議是兩個都上，不同的叢集採用不同的方案，甚至透過多網路卡同時採用underlay和overlay。即便僅有一種需求，也兩種方案都規劃到位，保證未來擴充的可能性。

在建設思維方面，可以參考IaaS的網路建設思維。IaaS典型的網路思維是三網分離、四網分離，容器網路目前規劃中，以前不太考慮這種方案，這是因為以前更多是IaaS負責基礎設施網路，但是如果一旦在裸金屬上部署容器平臺，那麼IaaS原來遇到的問題，今天容器平臺也會遇到。

在容器網路與外部網路通訊管控方面，可以透過統一的接入點(ingress、egress)管控容器內網的網路互訪，加強到“穩態”和“敏態”之間的安全互動。

在networkpolicy管理方面，如果有可能，更多采用networkpolicy為每個應用設定安全管控策略，這也是更“雲原生”的一種做法。

從叢集管理角度來看，容器雲有多個叢集，其中高併發高效能叢集中，宿主機上使用傳統網路，容器網路使用ovs。高容量高擴充套件性的叢集，宿主機上採用IaaS的基於VPC隔離的SDN網路，容器網路使用CNI元件，直接offload到宿主機網路上。

如何打造高效能的容器網路?

一些銀行雖然針對傳統網路已經做了很多最佳化工作，由於網路外掛的簡化，還有許多效能問題沒有解決，也許這些問題在容器雲裡不是問題，但是到金融場景裡就是比較大的挑戰了。

因此，我們需要一個工具實現從傳統網路向容器網路的平滑過渡，目前業內也已經出現了一些比較好的CNI方案。以目前比較活躍的Kube-OVN網路方案為例，它以成熟的OVS作為容器網路底座，透過將OpenStack領域成熟的網路功能平移到Kubernetes，融合了安全強化、智慧運維、硬體加速等多方面的特性，極大增強了Kubernetes容器網路的安全性、可運維性、管理性和效能。

透過Kube-OVN的一些調優，可以實現和現有容器網路有同等流量效能，並未發生效能損耗的現象。比如某股份制銀行，之前用到Calico方案，是最接近於物理網路效能的吞吐量，透過對比，Kube-OVN在效能上與Calico是相當的，另外它還可以支援OVS、DPDK這種自定義協議棧以及硬體加速方案，可以提升整個的容器效能。通常金融行業在上核心系統時要經過嚴格的容器網路效能的壓測，測試結果基本能達到預期，解決了效能上的後顧之憂。

另外還結合了一些在不同的銀行裡落地的經驗，尤其是把一些安全或者管控、監管側的要求，結合起來做了相應的構建，能夠有效地幫助銀行使用者構建更加適配金融雲原生的高效能容器網路。

最後，希望大家都能夠依據自身企業的實際情況，順利構建高併發、高可用、高效能的雲原生容器網路，穩健、高效地實現雲原生化轉型。