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

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

隨著銀行應用數量和類型的進一步增多，對網絡復雜度的要求也越來越高。銀行的應用有自身特點，銀行應用的管理級別不同，訪問特色也不同，需要考慮如何兼容傳統網絡架構，實現傳統網絡和容器網絡之間的互聯互通，同時，傳統應用容器化遷移后如何實現固定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這種自定義協議棧以及硬件加速方案，可以提升整個的容器性能。通常金融行業在上核心系統時要經過嚴格的容器網絡性能的壓測，測試結果基本能達到預期，解決了性能上的后顧之憂。

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

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