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

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

隨著銀行應用數(shù)量和類型的進一步增多，對網(wǎng)絡復雜度的要求也越來越高。銀行的應用有自身特點，銀行應用的管理級別不同，訪問特色也不同，需要考慮如何兼容傳統(tǒng)網(wǎng)絡架構，實現(xiàn)傳統(tǒng)網(wǎng)絡和容器網(wǎng)絡之間的互聯(lián)互通，同時，傳統(tǒng)應用容器化遷移后如何實現(xiàn)固定IP，以及對于容器多網(wǎng)絡平面、多網(wǎng)卡的管理，多租戶和跨云網(wǎng)絡、容器流量的監(jiān)測、調(diào)度與QoS等也都面臨新的挑戰(zhàn)。

目前有很多銀行容器網(wǎng)絡的內(nèi)部其實是一個“黑盒”，容器內(nèi)部和外部的網(wǎng)絡沒有打通，也無法實現(xiàn)跨云多網(wǎng)絡集群的互通，亟需進行轉型改造。

在這種壓力下，構建高性能的容器網(wǎng)絡就顯得尤為重要，然而：

• 兩地三中心架構中的容器網(wǎng)絡怎么改造可用性更高？

• 高并發(fā)場景下，銀行的容器網(wǎng)絡如何規(guī)劃？

• 如何打造高性能的容器網(wǎng)絡？

本篇文章將為你解答。

兩地三中心架構中的容器網(wǎng)絡怎么改造可用性更高？

面對應用的高可用性需求，很多銀行都在積極建設兩地三中心，或者異地災備建設。那么如何對接或改造容器平臺的網(wǎng)絡，以滿足容器平臺中應用與傳統(tǒng)虛擬機、物理機中舊業(yè)務系統(tǒng)的相互通信，避免或盡可能減少對銀行現(xiàn)有網(wǎng)絡管理模式的沖擊呢？

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

如果容器平臺的宿主節(jié)點在用IaaS的虛擬機，且啟用了SDN網(wǎng)絡，容器平臺啟用的CNI特性，則容器POD的應用可以和IaaS虛擬機的業(yè)務應用直接通信。如果和傳統(tǒng)網(wǎng)絡中的舊應用通信，則需要開啟IaaS的NAT特性或者為宿主節(jié)點配置EIP地址。

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

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

高并發(fā)場景下，銀行的容器網(wǎng)絡如何規(guī)劃？

在高并發(fā)場景下，銀行傳統(tǒng)的網(wǎng)絡架構相對缺少靈活性，已無法滿足日益增長的敏態(tài)業(yè)務需求。采用容器后，容器網(wǎng)絡如何兼容傳統(tǒng)網(wǎng)絡和安全管理，并提供擴展的靈活性，是每一個銀行用戶都在關注的問題。

我們在金融行業(yè)的大量實踐中發(fā)現(xiàn)，云原生的平臺化思維和傳統(tǒng)IT的條線式思維存在著一定矛盾。云原生希望通過一個yaml文件描述應用，所有的部署工藝、應用的計算、存儲、網(wǎng)絡應該能夠自動化生成，而銀行專門的網(wǎng)絡部門都有嚴格定義的網(wǎng)絡規(guī)范，它們之間的矛盾在銀行業(yè)是特別突出的。

從實際落地的角度來看，可以采取以下幾點建議來有針對性地解決這個矛盾，合理規(guī)劃銀行的容器網(wǎng)絡。

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

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

在容器網(wǎng)絡與外部網(wǎng)絡通信管控方面，可以通過統(tǒng)一的接入點（ingress、egress）管控容器內(nèi)網(wǎng)的網(wǎng)絡互訪，加強到“穩(wěn)態(tài)”和“敏態(tài)”之間的安全交互。

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

從集群管理角度來看，容器云有多個集群，其中高并發(fā)高性能集群中，宿主機上使用傳統(tǒng)網(wǎng)絡，容器網(wǎng)絡使用ovs。高容量高擴展性的集群，宿主機上采用IaaS的基于VPC隔離的SDN網(wǎng)絡，容器網(wǎng)絡使用CNI組件，直接offload到宿主機網(wǎng)絡上。

如何打造高性能的容器網(wǎng)絡？

一些銀行雖然針對傳統(tǒng)網(wǎng)絡已經(jīng)做了很多優(yōu)化工作，由于網(wǎng)絡插件的簡化，還有許多性能問題沒有解決，也許這些問題在容器云里不是問題，但是到金融場景里就是比較大的挑戰(zhàn)了。

因此，我們需要一個工具實現(xiàn)從傳統(tǒng)網(wǎng)絡向容器網(wǎng)絡的平滑過渡，目前業(yè)內(nèi)也已經(jīng)出現(xiàn)了一些比較好的CNI方案。以目前比較活躍的Kube-OVN網(wǎng)絡方案為例，它以成熟的OVS作為容器網(wǎng)絡底座，通過將OpenStack領域成熟的網(wǎng)絡功能平移到Kubernetes，融合了安全強化、智能運維、硬件加速等多方面的特性，極大增強了Kubernetes容器網(wǎng)絡的安全性、可運維性、管理性和性能。

通過Kube-OVN的一些調(diào)優(yōu)，可以實現(xiàn)和現(xiàn)有容器網(wǎng)絡有同等流量性能，并未發(fā)生性能損耗的現(xiàn)象。比如某股份制銀行，之前用到Calico方案，是最接近于物理網(wǎng)絡性能的吞吐量，通過對比，Kube-OVN在性能上與Calico是相當?shù)?，另外它還可以支持OVS、DPDK這種自定義協(xié)議棧以及硬件加速方案，可以提升整個的容器性能。通常金融行業(yè)在上核心系統(tǒng)時要經(jīng)過嚴格的容器網(wǎng)絡性能的壓測，測試結果基本能達到預期，解決了性能上的后顧之憂。

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

最后，希望大家都能夠依據(jù)自身企業(yè)的實際情況，順利構建高并發(fā)、高可用、高性能的云原生容器網(wǎng)絡，穩(wěn)健、高效地實現(xiàn)云原生化轉型。