銀行容器云平臺(tái)建設(shè)的需求分析與關(guān)鍵設(shè)計(jì)

1、 實(shí)用參考：銀行容器云平臺(tái)建設(shè)的需求分析與關(guān)鍵設(shè)計(jì) 【摘要】容器平臺(tái)的建設(shè)要考慮場景、技術(shù)、系統(tǒng)對(duì)接、成本、人員技能等因素，有不小的復(fù)雜度。本文從一個(gè)最精簡容器平臺(tái)所需考慮的各個(gè)方面，結(jié)合作者的項(xiàng)目實(shí)踐，提出供大家參考的建議。目 錄 TOC o 1-3 h z u HYPERLINK l _Toc65359145 銀行容器云平臺(tái)建設(shè)的需求分析與關(guān)鍵設(shè)計(jì) PAGEREF _Toc65359145 h 1 HYPERLINK l _Toc65359146 1 銀行建設(shè)容器平臺(tái)的背景 PAGEREF _Toc65359146 h 4 HYPERLINK l _Toc65359147 2 需求分析 P

2、AGEREF _Toc65359147 h 4 HYPERLINK l _Toc65359148 3 業(yè)務(wù)架構(gòu) PAGEREF _Toc65359148 h 5 HYPERLINK l _Toc65359149 4 關(guān)鍵設(shè)計(jì) PAGEREF _Toc65359149 h 7 HYPERLINK l _Toc65359150 4.1 資源池管理 PAGEREF _Toc65359150 h 7 HYPERLINK l _Toc65359151 4.2 網(wǎng)絡(luò)設(shè)計(jì) PAGEREF _Toc65359151 h 8 HYPERLINK l _Toc65359152 4.2.1 技術(shù)方案選擇 PAGER

3、EF _Toc65359152 h 8 HYPERLINK l _Toc65359153 4.2.2 網(wǎng)絡(luò)拓?fù)湟?guī)劃 PAGEREF _Toc65359153 h 12 HYPERLINK l _Toc65359154 4.4.1 應(yīng)用編排 PAGEREF _Toc65359154 h 14 HYPERLINK l _Toc65359155 4.4.2 生命周期管理 PAGEREF _Toc65359155 h 15 HYPERLINK l _Toc65359156 4.5 安全管理 PAGEREF _Toc65359156 h 16 HYPERLINK l _Toc65359157 4.5.1

4、 對(duì)接安全合規(guī)體系 PAGEREF _Toc65359157 h 17 HYPERLINK l _Toc65359158 4.5.2 多租戶隔離 PAGEREF _Toc65359158 h 17 HYPERLINK l _Toc65359159 4.5.3 應(yīng)用等級(jí)隔離 PAGEREF _Toc65359159 h 18 HYPERLINK l _Toc65359160 4.6 監(jiān)控日志 PAGEREF _Toc65359160 h 19 HYPERLINK l _Toc65359161 4.6.1 監(jiān)控 PAGEREF _Toc65359161 h 19 HYPERLINK l _Toc6

5、5359162 4.6.2 日志 PAGEREF _Toc65359162 h 20 HYPERLINK l _Toc65359163 5 總結(jié)和建議 PAGEREF _Toc65359163 h 211 銀行建設(shè)容器平臺(tái)的背景隨著互聯(lián)網(wǎng)金融的興起，互聯(lián)網(wǎng)企業(yè)依托互聯(lián)網(wǎng)，特別是移動(dòng)互聯(lián)網(wǎng)為公眾提供越來越多方便快捷、穩(wěn)定高效的金融類服務(wù)，對(duì)傳統(tǒng)的銀行業(yè)務(wù)帶來了很大沖擊。作為應(yīng)對(duì)，傳統(tǒng)銀行也在業(yè)務(wù)上不斷創(chuàng)新，帶來對(duì)IT基礎(chǔ)設(shè)施和應(yīng)用架構(gòu)方面進(jìn)行轉(zhuǎn)型升級(jí)的要求。例如為了支撐電商促銷活動(dòng)對(duì)銀行帶來的高峰期海量支付請(qǐng)求，某銀行很早就對(duì)支付渠道相關(guān)業(yè)務(wù)應(yīng)用進(jìn)行微服務(wù)架構(gòu)改造，由此帶來了容器技術(shù)的研究和運(yùn)用

6、。此銀行的多年實(shí)踐證明，采用容器技術(shù)平臺(tái)很好地支撐了新的業(yè)務(wù)模式和業(yè)務(wù)容量?；跇I(yè)務(wù)發(fā)展的需要，和快速進(jìn)步的金融科技技術(shù)，越來越多的傳統(tǒng)銀行在思考自身的互聯(lián)網(wǎng)金融戰(zhàn)略、金融云規(guī)劃等。其中重要內(nèi)容之一，是希望從技術(shù)層面更有效地支持業(yè)務(wù)創(chuàng)新，如微服務(wù)架構(gòu)、更好的靈活性、擴(kuò)展性、高可用性、更高效的業(yè)務(wù)上線效率等，因此跟上云計(jì)算技術(shù)發(fā)展的趨勢，建設(shè)并推廣適合自身的基于容器技術(shù)的云平臺(tái)是關(guān)鍵任務(wù)。2 需求分析銀行建設(shè)容器平臺(tái)，不僅需要為基于微服務(wù)架構(gòu)的新業(yè)務(wù)提供容器化運(yùn)行和管控平臺(tái)之外，還必須非常重視滿足金融行業(yè)嚴(yán)苛的監(jiān)管和安全要求。這樣的定位決定了在銀行建設(shè)容器平臺(tái)除了要具備市場上大多數(shù)容器平臺(tái)產(chǎn)品的

7、能力，還應(yīng)該為銀行的特殊監(jiān)管需求進(jìn)行定制。因此制定銀行容器平臺(tái)的需求時(shí)，建議考慮包括的方面有：管理大規(guī)模容器集群能力，包括：提供容器所需的高可用集群、資源池管理、網(wǎng)絡(luò)通信方案、存儲(chǔ)方案、編排調(diào)度引擎、微服務(wù)運(yùn)行框架、鏡像管理、事件告警、集群監(jiān)控和日志收集等。為滿足金融業(yè)務(wù)的監(jiān)管和安全要求，平臺(tái)需要考慮應(yīng)用的高可用性和業(yè)務(wù)連續(xù)性、多租戶安全隔離、不同等級(jí)業(yè)務(wù)隔離、防火墻策略、安全漏洞掃描、鏡像安全、后臺(tái)運(yùn)維的4A納管、審計(jì)日志；如果容器平臺(tái)還對(duì)公網(wǎng)提供訪問，那么還需要考慮訪問鏈路加密、安全證書等。還有一個(gè)重要方面是，銀行的金融云是一個(gè)范圍更大的復(fù)雜云環(huán)境，容器平臺(tái)通常是這個(gè)復(fù)雜系統(tǒng)中的一部分，因

8、此容器平臺(tái)還要遵從銀行已有IT技術(shù)規(guī)范和運(yùn)維要求，例如可能還需要考慮：支持銀行自身的應(yīng)用發(fā)布體系、持續(xù)集成系統(tǒng)、應(yīng)用建模規(guī)范、高可用管理策略對(duì)接金融云底層資源池（例如IaaS），遵從云計(jì)算資源的統(tǒng)一管理和分配對(duì)接或改造容器平臺(tái)的網(wǎng)絡(luò)，以滿足容器平臺(tái)中應(yīng)用與傳統(tǒng)虛擬機(jī)、物理機(jī)中舊業(yè)務(wù)系統(tǒng)的相互通信，避免或盡可能減少對(duì)銀行現(xiàn)有網(wǎng)絡(luò)管理模式的沖擊對(duì)接統(tǒng)一身份驗(yàn)證、和整個(gè)金融云其它系統(tǒng)采用統(tǒng)一的租戶定義、角色定義、資源配額定義等對(duì)接漏洞掃描、集中監(jiān)控系統(tǒng)、日志分析系統(tǒng)等已有周邊系統(tǒng)3 業(yè)務(wù)架構(gòu)基于對(duì)容器平臺(tái)的需求分析，可以用如下的業(yè)務(wù)架構(gòu)圖描述容器平臺(tái)應(yīng)提供的業(yè)務(wù)能力、以及容器平臺(tái)在銀行可能和周邊系統(tǒng)

9、的對(duì)接關(guān)系：各業(yè)務(wù)模塊提供的功能，以及可能需要集成、對(duì)接的情況是：4 關(guān)鍵設(shè)計(jì)以下討論業(yè)務(wù)架構(gòu)中各個(gè)業(yè)務(wù)模塊的關(guān)鍵設(shè)計(jì)思路。4.1 資源池管理容器平臺(tái)資源池管理負(fù)責(zé)容器運(yùn)行所需的計(jì)算、存儲(chǔ)資源申請(qǐng)、分配、容量管理，以及適合的容器網(wǎng)絡(luò)通信方案。容器網(wǎng)絡(luò)方案比較復(fù)雜，稍后專門論述，這里先探討關(guān)于計(jì)算和存儲(chǔ)資源的管理。對(duì)于計(jì)算和存儲(chǔ)資源的申請(qǐng)、分配、容量管理，可能的兩種做法是：按照容量預(yù)估，預(yù)先為容器平臺(tái)分配預(yù)測的計(jì)算節(jié)點(diǎn)、存儲(chǔ)容量的資源，在容器平臺(tái)中將這些資源注冊到容器集群中使用。當(dāng)需要擴(kuò)容或刪除某些資源時(shí)，重復(fù)相應(yīng)的動(dòng)作。對(duì)接外部的資源管理和供給系統(tǒng)，通常是IaaS系統(tǒng)或者具備資源供給能力的自動(dòng)

10、化系統(tǒng)，通過調(diào)用外部系統(tǒng)的接口，容器平臺(tái)按需獲取所需的計(jì)算和存儲(chǔ)資源。第一種做法的優(yōu)勢在于系統(tǒng)簡單，不需要對(duì)接外部資源管理系統(tǒng)，適合技術(shù)驗(yàn)證平臺(tái)，或容量不需要頻繁變化的情況。對(duì)于生產(chǎn)系統(tǒng)或復(fù)雜的測試系統(tǒng)，基本上都應(yīng)該考慮第二種做法，雖然帶來了系統(tǒng)集成的復(fù)雜性，但容器平臺(tái)可以借助外部的IaaS等系統(tǒng)，確保所申請(qǐng)的資源的高可用性，例如可以借助底層IaaS系統(tǒng)的功能，確保容器平臺(tái)獲得的宿主機(jī)均勻分布在不同的可用區(qū)AZ，這些不同的可用區(qū)AZ可能具備不同的供電、網(wǎng)絡(luò)連接設(shè)備等，通常對(duì)應(yīng)于數(shù)據(jù)中心不同的物理區(qū)域、樓層或樓宇，由此減少某一故障導(dǎo)致大部分甚至全部容器宿主機(jī)癱瘓的可能性；同時(shí)，第二種做法讓資源申

11、請(qǐng)和獲得無需人工介入，因此能做到容器平臺(tái)資源的按需自動(dòng)申請(qǐng)、彈性擴(kuò)容。目前市場上的容器平臺(tái)開源技術(shù)方案，或商業(yè)容器平臺(tái)，大多具備了和IaaS系統(tǒng)的集成能力，或者需要開發(fā)的相關(guān)集成邏輯也并不復(fù)雜，例如只需通過IaaS的接口獲取虛擬機(jī)，并用自動(dòng)化任務(wù)在虛擬機(jī)中執(zhí)行容器平臺(tái)添加計(jì)算節(jié)點(diǎn)的命令，即可完成從資源申請(qǐng)到自動(dòng)加入容器平臺(tái)的完整過程。4.2 網(wǎng)絡(luò)設(shè)計(jì)4.2.1 技術(shù)方案選擇在資源管理中，網(wǎng)絡(luò)的管理是比較復(fù)雜的。對(duì)于容器平臺(tái)可能的網(wǎng)絡(luò)方案，基本上分為以下幾類：原生NAT方案隧道方案（Overlay），代表性的方案有Flannel、Docker Overlay、OVS等路由方案，代表性的方案有Ca

12、lico、MacVlan自定義網(wǎng)絡(luò)方案原生NAT方案中，容器借助宿主機(jī)端口映射、以及在宿主機(jī)上配置的iptables規(guī)則，對(duì)容器的網(wǎng)絡(luò)數(shù)據(jù)包進(jìn)行NAT轉(zhuǎn)換，再通過宿主機(jī)的路由轉(zhuǎn)發(fā)實(shí)現(xiàn)不同容器間跨主機(jī)的網(wǎng)絡(luò)通信。這種方式的優(yōu)勢是原生支持、簡單、容器實(shí)例不需要額外消耗骨干網(wǎng)絡(luò)IP地址、也不會(huì)增加在宿主機(jī)間傳遞數(shù)據(jù)包的長度；但是缺陷也是明顯的：同一宿主機(jī)上不同容器在宿主機(jī)上的映射端口必須區(qū)分開以避免端口沖突；容器遷移到不同宿主機(jī)時(shí)，很可能需要改變所映射的宿主機(jī)端口，控制比較麻煩；通過NAT通信使得容器網(wǎng)絡(luò)數(shù)據(jù)包在骨干網(wǎng)上使用的不是自身的IP，給防火墻策略帶來不便；端口映射帶來的網(wǎng)絡(luò)性能損失，筆者自己

13、的環(huán)境下測試結(jié)果是，使用NAT方式的容器在進(jìn)行跨宿主機(jī)通信是，吞吐率只能達(dá)到宿主機(jī)間吞吐率的1/3。因此，原生的NAT網(wǎng)絡(luò)比較適合小規(guī)模的功能驗(yàn)證和試驗(yàn)環(huán)境，網(wǎng)絡(luò)性能不是重要的考慮因素，測試的場景中也不涉及很多容器遷移、防火墻安全等問題。很顯然，在銀行正式的測試環(huán)境、生產(chǎn)環(huán)境下，采用原生NAT方案不足以滿足功能、性能和安全監(jiān)管要求。隧道方案，也就是Overlay方案，借助容器宿主機(jī)網(wǎng)絡(luò)，構(gòu)建出一個(gè)對(duì)于容器來說三層路由可達(dá)虛擬網(wǎng)絡(luò)。具體做法是通過把容器網(wǎng)絡(luò)數(shù)據(jù)包整體封裝放進(jìn)宿主機(jī)網(wǎng)絡(luò)報(bào)文，由宿主機(jī)網(wǎng)絡(luò)轉(zhuǎn)發(fā)到目標(biāo)容器所在的宿主機(jī)，再由目標(biāo)容器所在的宿主機(jī)對(duì)報(bào)文進(jìn)行拆解得到容器網(wǎng)絡(luò)數(shù)據(jù)包，交給容器網(wǎng)

14、橋，由容器網(wǎng)橋再轉(zhuǎn)發(fā)到目標(biāo)容器。隧道方案的好處是沒有NAT方案的端口沖突問題、不消耗額外的骨干網(wǎng)絡(luò)IP、與現(xiàn)有網(wǎng)絡(luò)技術(shù)不產(chǎn)生沖突因此靈活性大、通過構(gòu)建不同的VLAN虛擬網(wǎng)絡(luò)很容易實(shí)現(xiàn)網(wǎng)絡(luò)隔離、網(wǎng)絡(luò)性能損失比原生NAT方案小，在滿足銀行業(yè)務(wù)功能和安全監(jiān)管要求的同時(shí)，對(duì)性能也有一定的照顧。因此隧道（Overlay）方案目前是應(yīng)用比較多的選擇，在技術(shù)上的可選擇性也最大，方案成熟度也比較高，所以相對(duì)其他的方案，隧道方案的實(shí)施、定制化、維護(hù)的成本比較低。不過事情都有兩面，如果選擇隧道方案，您還是有一些不可回避問題需要考慮解決：如果容器平臺(tái)中運(yùn)行業(yè)務(wù)與其它平臺(tái)上運(yùn)行業(yè)務(wù)需要通信，則需要配置從容器外部訪問容

15、器的路由，否則容器的地址從容器平臺(tái)外部不能直接路由訪問。由于容器動(dòng)態(tài)變化和跨主機(jī)遷移的特點(diǎn)，配置從外部訪問容器的路由是一個(gè)比較復(fù)雜的問題，不僅需要在外部路由器、宿主機(jī)路由表中進(jìn)行配置，還需要將這些配置動(dòng)作和容器的啟停聯(lián)動(dòng)起來，這需要復(fù)雜的SDN能力；由于容器網(wǎng)絡(luò)數(shù)據(jù)包在底層網(wǎng)絡(luò)上傳輸時(shí)被封裝在宿主機(jī)網(wǎng)絡(luò)報(bào)文中，因此對(duì)普通防火墻來說，容器網(wǎng)絡(luò)數(shù)據(jù)包的地址不可見。如果需要對(duì)容器數(shù)據(jù)包進(jìn)行精確的防火墻規(guī)則設(shè)置，代價(jià)很大，幾乎不可行；變通的方法可以考慮把需要進(jìn)行網(wǎng)絡(luò)隔離的容器，在啟動(dòng)時(shí)指定所在的VLAN，通過不同的VLAN來實(shí)現(xiàn)隔離；由于容器網(wǎng)絡(luò)數(shù)據(jù)包需要被封裝在底層宿主機(jī)網(wǎng)絡(luò)報(bào)文中，因此會(huì)增加底層網(wǎng)

16、絡(luò)數(shù)據(jù)包的長度，當(dāng)您的底層網(wǎng)絡(luò)也是Overlay網(wǎng)絡(luò)，或者Overlay的層數(shù)較多時(shí)，會(huì)影響網(wǎng)絡(luò)數(shù)據(jù)包承載數(shù)據(jù)的效率，并且封裝和拆解數(shù)據(jù)包的次數(shù)也會(huì)顯著影響網(wǎng)絡(luò)的傳輸效率，對(duì)于性能關(guān)鍵的場景，這個(gè)問題也需要引起重視。路由方案通過路由技術(shù)從三層或者二層實(shí)現(xiàn)跨主機(jī)容器互通，沒有NAT，沒有Overlay方案需要的數(shù)據(jù)包封裝和拆解，每一個(gè)容器具有路由可達(dá)的IP地址，且可以做到從容器平臺(tái)外部路由可達(dá)。這種網(wǎng)絡(luò)方案的好處是性能損失小、外部路由可達(dá)、傳統(tǒng)的防火墻仍然能正常發(fā)揮作用等。但缺點(diǎn)是：IP地址消耗大，如果容器數(shù)量規(guī)模大，特別是采用微服務(wù)架構(gòu)后，大量的容器IP資源被消耗，且可能出現(xiàn)大量IP沖擊到路由

17、表里，導(dǎo)致路由效率降低等問題；容器平臺(tái)外部對(duì)容器網(wǎng)絡(luò)中網(wǎng)絡(luò)實(shí)體的變化仍不能感知，例如新的容器創(chuàng)建或發(fā)生跨主機(jī)遷移時(shí)，以Calico方案為例，F(xiàn)elix和BGP client模塊可以保證容器網(wǎng)絡(luò)內(nèi)的路由策略更新，但由于容器平臺(tái)外界不能感知容器的變化，外部到此新創(chuàng)建容器的路由則沒辦法被自動(dòng)創(chuàng)建，仍然需要額外的路由更新工作補(bǔ)充。再來探討自定義網(wǎng)絡(luò)方案，本文所提的自定義網(wǎng)絡(luò)方案泛指針對(duì)自身特定需求，而在既有網(wǎng)絡(luò)技術(shù)基礎(chǔ)之上進(jìn)行改造，或者將不同的網(wǎng)絡(luò)技術(shù)進(jìn)行整合、打通而形成的特殊方案。例如在某銀行，容器平臺(tái)作為整個(gè)金融云平臺(tái)的一部分，在設(shè)計(jì)容器網(wǎng)絡(luò)時(shí)，需要考慮整個(gè)金融云網(wǎng)絡(luò)管理上的一致性，由此要求容器網(wǎng)

18、絡(luò)具備和底層宿主機(jī)網(wǎng)絡(luò)相同的網(wǎng)絡(luò)層級(jí)、IP地址規(guī)劃、子網(wǎng)劃分規(guī)則，并能夠?qū)崿F(xiàn)容器實(shí)例和容器平臺(tái)以外的直接路由互通，以便能夠?qū)θ萜骶W(wǎng)絡(luò)復(fù)用既有的SDN控制器管理、防火墻、安全漏掃、網(wǎng)絡(luò)抓包分析工具等的能力。因此該銀行在建設(shè)自己容器平臺(tái)網(wǎng)絡(luò)時(shí)，對(duì)接了IAAS的Neutron+SDN進(jìn)行統(tǒng)一網(wǎng)絡(luò)管理，工作原理是：當(dāng)容器平臺(tái)需要為新的租戶分配網(wǎng)絡(luò)資源時(shí)，通知Neutron，由Neutron對(duì)接的SDN控制器按照預(yù)先定義的規(guī)則為容器平臺(tái)分配所需的子網(wǎng)和網(wǎng)絡(luò)地址空間；開發(fā)網(wǎng)絡(luò)驅(qū)動(dòng)，實(shí)現(xiàn)CNI接口。當(dāng)容器平臺(tái)創(chuàng)建新的容器實(shí)例時(shí)，網(wǎng)絡(luò)驅(qū)動(dòng)調(diào)用Neutron接口創(chuàng)建port，為容器實(shí)例在子網(wǎng)中分配MAC和IP，

19、并把IP綁定到容器網(wǎng)卡（類似nova-compute的工作），然后通知Neutron容器IP配置成功；容器平臺(tái)記錄容器的IP地址，作為進(jìn)行服務(wù)注冊、服務(wù)發(fā)現(xiàn)、監(jiān)控服務(wù)的基礎(chǔ)；Neutron和SDN聯(lián)動(dòng)，完成為容器實(shí)例設(shè)置相關(guān)的路由策略、防火墻策略等。這種方案的效果即保證網(wǎng)絡(luò)效率、也能完全融入現(xiàn)有網(wǎng)絡(luò)管理體系、還能做到完全的SDN聯(lián)動(dòng)，但復(fù)雜程度高，定制的成本也比較大，且由于完全基于路由而沒有Overlay，也存在IP地址消耗比較大的問題。需要聲明以上只是以某個(gè)特定銀行的定制方案為例，讀者所在的銀行和企業(yè)可能有自己對(duì)容器網(wǎng)絡(luò)的需求，以及自己的技術(shù)考慮，因此自定義網(wǎng)絡(luò)方案的可能性多種多樣，最終實(shí)現(xiàn)

20、的能力和代價(jià)也差別很大。如何選擇容器平臺(tái)的網(wǎng)絡(luò)技術(shù)方案會(huì)相當(dāng)復(fù)雜，涉及技術(shù)、場景、人員技能、成本等多方面。容器平臺(tái)網(wǎng)絡(luò)方案直接關(guān)系到平臺(tái)的容量、效率、實(shí)施和運(yùn)維成本，因此選擇需要充分論證，考慮容器平臺(tái)的定位、規(guī)模發(fā)展、承載的業(yè)務(wù)場景、對(duì)現(xiàn)有網(wǎng)絡(luò)的影響、對(duì)與集中監(jiān)控系統(tǒng)、安全合規(guī)檢查系統(tǒng)集成的影響等，需要認(rèn)真評(píng)估需求、平衡收益和成本。4.2.2 網(wǎng)絡(luò)拓?fù)湟?guī)劃除了技術(shù)方案，網(wǎng)絡(luò)拓?fù)湟?guī)劃是網(wǎng)絡(luò)設(shè)計(jì)的另一個(gè)重要方面，不僅涉及網(wǎng)絡(luò)管理復(fù)雜度，還直接關(guān)系到安全合規(guī)。傳統(tǒng)上銀行科技部門會(huì)為不同安全等級(jí)的應(yīng)用劃分不同的網(wǎng)絡(luò)區(qū)，分別提供不同的安全等級(jí)保護(hù)；也可能會(huì)根據(jù)運(yùn)行業(yè)務(wù)的特點(diǎn)，分為可直接對(duì)外提供服務(wù)的網(wǎng)絡(luò)

21、隔離區(qū)，和只在內(nèi)部運(yùn)行業(yè)務(wù)處理和數(shù)據(jù)處理的業(yè)務(wù)區(qū)、數(shù)據(jù)庫區(qū)等。在規(guī)劃容器平臺(tái)的網(wǎng)絡(luò)拓?fù)鋾r(shí)，建議保留這些已經(jīng)成熟并實(shí)踐多年的網(wǎng)絡(luò)區(qū)域劃分方法，保持遵守對(duì)安全合規(guī)的監(jiān)管要求。同時(shí)，根據(jù)對(duì)容器平臺(tái)的定位和管理策略，容器平臺(tái)可能需要在傳統(tǒng)的網(wǎng)絡(luò)拓?fù)渖献鱿鄳?yīng)的擴(kuò)充，例如：如果容器平臺(tái)是金融云的一部分，網(wǎng)絡(luò)拓?fù)浔仨氈С侄嘧鈶舻母綦x；容器平臺(tái)中的容器和宿主機(jī)都運(yùn)行在網(wǎng)絡(luò)中，容器運(yùn)行應(yīng)用屬于業(yè)務(wù)，而宿主機(jī)運(yùn)行容器屬于資源，建議把容器所在的業(yè)務(wù)域和宿主機(jī)所在的資源域劃分到不同的網(wǎng)絡(luò)區(qū)，分別使用不同的管理和訪問策略，保留足夠的靈活性滿足不同的用戶需求；容器平臺(tái)自身運(yùn)行所需的管理節(jié)點(diǎn)、鏡像倉庫、計(jì)算節(jié)點(diǎn)可以考慮放到

22、不同的網(wǎng)絡(luò)區(qū)，以滿足它們各自不同的運(yùn)行要求。例如鏡像倉庫可能需要提供對(duì)公網(wǎng)的服務(wù)，以便用戶從公網(wǎng)瀏覽和管理鏡像、管理節(jié)點(diǎn)可能需要運(yùn)行在支持帶外管理的網(wǎng)絡(luò)區(qū)等。用下圖總結(jié)以上探討的銀行如何規(guī)劃容器平臺(tái)網(wǎng)絡(luò)拓?fù)涞膬?nèi)容：4.3 鏡像倉庫鏡像倉庫負(fù)責(zé)存儲(chǔ)和發(fā)布應(yīng)用的鏡像部署版本，在功能上并不復(fù)雜，但由于監(jiān)管要求和業(yè)務(wù)的特殊性，銀行高度關(guān)切生產(chǎn)環(huán)境的安全性，都要求用于生產(chǎn)發(fā)布的鏡像版本必須通過嚴(yán)格的測試階段，以及嚴(yán)密的安全檢查步驟，因此建議對(duì)生產(chǎn)環(huán)境運(yùn)行專用的生產(chǎn)鏡像倉庫；同時(shí)，在持續(xù)集成越來越普遍的情況下，為了保證開發(fā)和測試的方便，我們需要測試鏡像倉庫。建議生產(chǎn)鏡像庫和測試鏡像庫在物理上分開、網(wǎng)絡(luò)上的

23、連通通過防火墻策略做限制（只開放必須的端口用于鏡像同步）。在使用規(guī)則上，測試鏡像倉庫允許隨時(shí)的鏡像上傳和更新，通常都會(huì)對(duì)接持續(xù)集成系統(tǒng)；而對(duì)于生產(chǎn)鏡像倉庫，為了保證鏡像來源的安全、可控，建議限制為只能從測試鏡像同步，規(guī)定只有在測試鏡像倉庫中標(biāo)記為完成測試、經(jīng)過安全檢查的鏡像，由有相應(yīng)權(quán)限的賬號(hào)，在經(jīng)過必要的審批或者滿足一定規(guī)則的情況下，從測試鏡像倉庫中把鏡像同步到生產(chǎn)鏡像倉庫。一旦鏡像進(jìn)入生產(chǎn)鏡像倉庫，就被當(dāng)做正式的生產(chǎn)發(fā)布版本，接下來就按照銀行現(xiàn)有的生產(chǎn)發(fā)布和變更流程，在指定的變更窗口，從生產(chǎn)鏡像庫中拉取鏡像進(jìn)行部署，這樣做也很好地滿足了銀行的安全監(jiān)管要求。下圖總結(jié)建議的鏡像倉庫體系、和相關(guān)

24、工作流程：4.4 應(yīng)用管理應(yīng)用管理負(fù)責(zé)運(yùn)行基于容器鏡像的輕量級(jí)應(yīng)用或微服務(wù)，提供應(yīng)用的微服務(wù)編排能力、應(yīng)用全生命周期管理。4.4.1 應(yīng)用編排應(yīng)用編排的目的是為了給容器平臺(tái)上運(yùn)行的應(yīng)用進(jìn)行建模標(biāo)準(zhǔn)化，描述應(yīng)用運(yùn)行的資源需求、部署模式、部署參數(shù)、運(yùn)行時(shí)動(dòng)態(tài)規(guī)則（彈性伸縮、故障遷移等）。目前開源和商用容器平臺(tái)都已支持自己的應(yīng)用編排，例如Kubernetes的yaml文件方式，但對(duì)銀行來說，可能還存在一些不足：對(duì)銀行的特定需求支持不足，例如銀行應(yīng)用的安全等級(jí)、部署的網(wǎng)路區(qū)等這些特殊信息的描述；不同的容器編排系統(tǒng)、甚至同一編排系統(tǒng)的不同版本，可能存在編排語法不同、不兼容的問題。銀行的應(yīng)用建模是重要的資

25、產(chǎn)，不能允許由于版本升級(jí)、技術(shù)改造而導(dǎo)致眾多應(yīng)用的建模不兼容。因此建議容器平臺(tái)自定義應(yīng)用編排規(guī)范，如果容器平臺(tái)定位為銀行整體金融云的一部分，那么容器平臺(tái)的應(yīng)用編排應(yīng)兼容整體金融云的應(yīng)用建模規(guī)范，確保金融云上所有應(yīng)用建模的一致性。在用自定義的編排規(guī)范對(duì)應(yīng)用進(jìn)行標(biāo)準(zhǔn)化描述后，需要對(duì)底層的容器平臺(tái)進(jìn)行能力擴(kuò)充定制，對(duì)應(yīng)用編排信息進(jìn)行翻譯，變成容器平臺(tái)可以理解的信息，再根據(jù)這些信息對(duì)應(yīng)用進(jìn)行部署、升級(jí)和運(yùn)行管理。下面的圖描述了應(yīng)用建模、以及使用應(yīng)用建模進(jìn)行部署、升級(jí)和運(yùn)行管理的過程。4.4.2 生命周期管理應(yīng)用全生命周期管理負(fù)責(zé)應(yīng)用的上架、部署、升級(jí)、下架、支持運(yùn)行時(shí)動(dòng)態(tài)管理策略，還可支持雙活部署、同

26、城災(zāi)備切換等金融云高級(jí)能力。這部分功能可能需要對(duì)接金融云的應(yīng)用發(fā)布、高可用部署和切換模塊，提供整個(gè)金融云所有應(yīng)用統(tǒng)一的部署、高可用體驗(yàn)。在上一節(jié)應(yīng)用編排，我們討論了有關(guān)上架、部署、升級(jí)、運(yùn)行管理等，這里來看應(yīng)用的高可用部署和切換。容器平臺(tái)可以從實(shí)例、服務(wù)、應(yīng)用三個(gè)層級(jí)，分別實(shí)現(xiàn)應(yīng)用的高可用，分別是：實(shí)例級(jí)，即容器故障自動(dòng)恢復(fù)；服務(wù)級(jí)，即服務(wù)/微服務(wù)的多個(gè)實(shí)例的跨不同可用區(qū)部署；應(yīng)用級(jí)，即應(yīng)用跨數(shù)據(jù)中心切換。從單個(gè)運(yùn)行實(shí)例級(jí)別，可以采用容器故障自動(dòng)恢復(fù)機(jī)制，對(duì)發(fā)生故障的容器實(shí)例進(jìn)行快速的故障發(fā)現(xiàn)、自動(dòng)遷移和恢復(fù)?；旧祥_源和商業(yè)的容器集群管理系統(tǒng)都支持按照用戶預(yù)定義的規(guī)則，進(jìn)行故障檢測和實(shí)例恢復(fù)

27、。從單個(gè)服務(wù)級(jí)別，可以把一個(gè)服務(wù)或微服務(wù)的多個(gè)容器運(yùn)行實(shí)例，在跨多個(gè)可用區(qū)中進(jìn)行分布部署。在容器平臺(tái)在進(jìn)行資源池管理時(shí)，借助底層IaaS平臺(tái)，確保容器宿主機(jī)均勻分布在不同的可用區(qū)AZ中。當(dāng)在容器平臺(tái)部署一個(gè)服務(wù)或微服務(wù)的多個(gè)容器實(shí)例時(shí)，盡量把多個(gè)容器實(shí)例調(diào)度運(yùn)行在處于不同可用區(qū)AZ的宿主機(jī)上，這可以借助容器調(diào)度策略、以及事先對(duì)宿主機(jī)加標(biāo)簽以方便識(shí)別所在的可用區(qū)來配合完成。絕大多數(shù)情況下，我們都有機(jī)會(huì)從實(shí)例級(jí)別、服務(wù)級(jí)別進(jìn)行努力，提高應(yīng)用的高可用性?，F(xiàn)在越來越多的銀行都在建設(shè)自己的多地或多中心系統(tǒng)，或者即有本地私有數(shù)據(jù)中心，也同時(shí)具備云端的數(shù)據(jù)中心。如果您有這樣的基礎(chǔ)設(shè)施，或有相關(guān)的建設(shè)目標(biāo)，那

28、么您還可以從更高的級(jí)別，即從整個(gè)應(yīng)用的級(jí)別來考慮高可用性。做法是在多個(gè)數(shù)據(jù)中心，對(duì)應(yīng)用進(jìn)行多活、或者主備的部署，把業(yè)務(wù)流量按照合適的比例分發(fā)到不同的數(shù)據(jù)中心進(jìn)行交易處理。多數(shù)據(jù)中心部署的一個(gè)關(guān)鍵問題是交易數(shù)據(jù)的一致性，由于分布式數(shù)據(jù)庫在數(shù)據(jù)一致性上目前并不成熟，分庫分表又會(huì)帶來額外的關(guān)聯(lián)復(fù)雜性，因此大多數(shù)銀行當(dāng)前階段選擇起來還很謹(jǐn)慎，而會(huì)繼續(xù)采用單個(gè)集中的主數(shù)據(jù)庫，加上位于不同數(shù)據(jù)中心的備庫，之間通過數(shù)據(jù)庫自身的同步技術(shù)、加上底層存儲(chǔ)系統(tǒng)的快速同步，確保備庫和主庫的數(shù)據(jù)保持一致，在進(jìn)行數(shù)據(jù)中心切換時(shí)，盡可能地減小數(shù)據(jù)丟失，即減小RPO。采用主備庫同步的方案，會(huì)對(duì)網(wǎng)絡(luò)低延遲有比較高的要求，這限制

29、了不同數(shù)據(jù)中心間的最遠(yuǎn)距離，通常位于同一城市區(qū)域、相距數(shù)十公里以內(nèi)是比較可行和普遍的。4.5 安全管理安全管理是滿足行業(yè)監(jiān)管要求必須考慮的問題，是銀行建設(shè)容器平臺(tái)的特殊要求。安全管理的難點(diǎn)在于涉及面廣，包括系統(tǒng)漏洞、病毒威脅、鏈路加密、攻擊防范、系統(tǒng)訪問權(quán)限上收、操作審計(jì)等，此外安全管理面對(duì)的安全威脅不斷地發(fā)展變化，也增加了防范的技術(shù)難度和持續(xù)的工作量。同時(shí)金融云和容器自身的特點(diǎn)，在傳統(tǒng)銀行安全管理的基礎(chǔ)上，還增加了多租戶隔離、角色管理、鏡像安全檢測等新問題。4.5.1 對(duì)接安全合規(guī)體系鑒于安全管理的復(fù)雜性，如果在容器平臺(tái)中單獨(dú)進(jìn)行安全管理，代價(jià)很高；而且安全管理也十分依賴長時(shí)間的積累，容器平

30、臺(tái)單獨(dú)進(jìn)行安全管理，也難免在一段時(shí)間內(nèi)出現(xiàn)各種安全問題紕漏。因此建議容器平臺(tái)在安全管理上直接對(duì)接銀行現(xiàn)有的安全管理防范體系，充分利用現(xiàn)有的各類安全工具、手段，在現(xiàn)有安全管理手段的基礎(chǔ)上，按需增加功能應(yīng)對(duì)容器平臺(tái)帶來的新需求新問題。這應(yīng)該是見效快、成本低、風(fēng)險(xiǎn)也比較低的方式。銀行面對(duì)嚴(yán)格的行業(yè)安全監(jiān)管要求，現(xiàn)有的安全管理防范體系，包括技術(shù)工具、工作流程和指導(dǎo)規(guī)范等都已經(jīng)相當(dāng)完備，例如系統(tǒng)漏洞掃描、補(bǔ)丁安裝、防病毒系統(tǒng)、SSL和證書申請(qǐng)、WAF、統(tǒng)一身份認(rèn)證和4A訪問管理、操作日志審計(jì)等。為了利用上這些能力，需要在容器平臺(tái)設(shè)計(jì)，特別是網(wǎng)絡(luò)方案的設(shè)計(jì)上，仔細(xì)考慮如何才能讓這些工具和手段對(duì)容器平臺(tái)發(fā)揮

31、作用。例如某銀行系統(tǒng)漏洞掃描的方式是由運(yùn)行在網(wǎng)絡(luò)中的掃描服務(wù)，定期地通過向被掃描目標(biāo)IP發(fā)送端口檢測報(bào)文，分析響應(yīng)結(jié)果來判斷是否存在系統(tǒng)漏洞，做出是否需要安裝補(bǔ)丁或者關(guān)閉被掃描目標(biāo)相關(guān)系統(tǒng)服務(wù)等決定。為了讓系統(tǒng)漏洞掃描服務(wù)能對(duì)容器平臺(tái)正常工作，那么在設(shè)計(jì)網(wǎng)絡(luò)方案時(shí)，讓漏洞掃描服務(wù)與容器平臺(tái)中的容器IP路由可達(dá)就是必須要考慮的問題。4.5.2 多租戶隔離如果容器平臺(tái)作為金融云的一部分，并計(jì)劃為不同的租戶提供服務(wù)，那么根據(jù)租戶對(duì)安全的要求，支持不同租戶的隔離也是要考慮的內(nèi)容。在之前討論網(wǎng)絡(luò)拓?fù)湟?guī)劃時(shí)，建議把不同租戶的容器運(yùn)行在各自不同的虛擬網(wǎng)絡(luò)VLAN中，并為不同的VLAN設(shè)置必須的防火墻規(guī)則、關(guān)

32、閉相關(guān)的路由來保證不同租戶的業(yè)務(wù)在網(wǎng)絡(luò)上隔離。由于容器共享宿主機(jī)內(nèi)核的特點(diǎn)，如果把不同租戶的容器運(yùn)行在同一臺(tái)宿主機(jī)上，租戶可能面臨來自其他租戶容器運(yùn)行帶來的不利影響，例如：資源競爭導(dǎo)致的性能下降；其他租戶容器應(yīng)用的bug導(dǎo)致的宿主機(jī)內(nèi)核運(yùn)行異常，進(jìn)而導(dǎo)致自己租戶容器的運(yùn)行故障；潛在的來自其他租戶的惡意容器應(yīng)用，利用共享內(nèi)核進(jìn)行攻擊和竊密。因此，建議容器平臺(tái)為不同的租戶分配各自專屬的、不同的資源池，租戶只能在屬于自己的宿主機(jī)上運(yùn)行自己的容器應(yīng)用。這雖然導(dǎo)致了資源利用率的降低，但在根本上回避了容器運(yùn)行依賴共享宿主機(jī)內(nèi)核、隔離性天生不如虛擬機(jī)的局限，這和主要基于虛擬機(jī)的IaaS平臺(tái)對(duì)多租戶隔離的做法

33、不同。4.5.3 應(yīng)用等級(jí)隔離除了不同租戶間的隔離，即使在同一租戶下，運(yùn)行不同安全等級(jí)的應(yīng)用，因?yàn)槿萜鞴蚕硐到y(tǒng)內(nèi)核的特點(diǎn)，應(yīng)用也面臨其它等級(jí)應(yīng)用的資源爭搶、故障影響等問題。另外，不同等級(jí)的應(yīng)用，往往要求不同級(jí)別的運(yùn)行環(huán)境高可用性、安全性，因此在同一租戶下，也應(yīng)該把不同等級(jí)的應(yīng)用隔離開，分別部署到各自專屬的資源池內(nèi)。下面的圖以兩個(gè)租戶、分別有不同的安全等級(jí)的應(yīng)用部署為例，描繪應(yīng)用的部署狀態(tài)：4.6 監(jiān)控日志4.6.1 監(jiān)控和安全管理類似，監(jiān)控體系也在銀行發(fā)展多年，特別是針對(duì)生產(chǎn)系統(tǒng)的監(jiān)控、告警體系，根據(jù)自身運(yùn)維的需要，不斷積累、優(yōu)化了多年，大多已經(jīng)比較完備；圍繞目前的監(jiān)控體系，也形成了成熟的應(yīng)急

34、方案、流程，人員技能和經(jīng)驗(yàn)也多圍繞既有生產(chǎn)監(jiān)控系統(tǒng)進(jìn)行培訓(xùn)、學(xué)習(xí)。因此，如果容器平臺(tái)沒有特別的需求，在銀行的生產(chǎn)環(huán)境下，建議將容器平臺(tái)的監(jiān)控體系對(duì)接目前的集中監(jiān)控系統(tǒng)，方便運(yùn)維人員對(duì)生產(chǎn)環(huán)境的統(tǒng)一監(jiān)控管理，既有的應(yīng)急方案、流程、人員技能和經(jīng)驗(yàn)都可以得到沿用。即使容器平臺(tái)有不同于傳統(tǒng)的監(jiān)控需求，例如：容器運(yùn)行不再關(guān)注單個(gè)容器實(shí)例的增加和消失，而只關(guān)注整體服務(wù)的可用性；新的業(yè)務(wù)應(yīng)用通過輸出標(biāo)準(zhǔn)化日志，對(duì)日志進(jìn)行分析提取業(yè)務(wù)性能數(shù)據(jù)、成功率。出現(xiàn)這些不同的需求，也建議用集中監(jiān)控系統(tǒng)進(jìn)行展示和告警，只是需要在集中監(jiān)控系統(tǒng)之外先進(jìn)行處理，再把處理后的結(jié)果對(duì)接到集中監(jiān)控系統(tǒng)。例如，我們不用再在集中監(jiān)控系統(tǒng)

35、中配置去監(jiān)控每一個(gè)容器實(shí)例的IP，而是由容器平臺(tái)檢查服務(wù)所需要的容器實(shí)例數(shù)量是否還在允許的最小值以上，只有當(dāng)實(shí)例數(shù)量低于接受的最小值，才給集中監(jiān)控系統(tǒng)發(fā)送告警，其它情況下只需要匯報(bào)當(dāng)前實(shí)例數(shù)量即可，不在乎實(shí)例數(shù)量的波動(dòng)。在設(shè)計(jì)具體的監(jiān)控時(shí)，應(yīng)把監(jiān)控進(jìn)行分類，分別處理。具體可分為：應(yīng)用和服務(wù)監(jiān)控資源監(jiān)控平臺(tái)監(jiān)控應(yīng)用和服務(wù)監(jiān)控關(guān)心業(yè)務(wù)服務(wù)的正確工作狀態(tài)，這可能需要通過調(diào)用平臺(tái)API、或通過應(yīng)用日志分析、特定端口響應(yīng)等方法來判斷，需要開發(fā)一定的邏輯處理，再把結(jié)果對(duì)接到集中監(jiān)控。資源監(jiān)控主要關(guān)注每個(gè)宿主機(jī)、以及計(jì)算節(jié)點(diǎn)集群的整體資源的使用情況，是否需要增加節(jié)點(diǎn)擴(kuò)容等，這一點(diǎn)基本上傳統(tǒng)的監(jiān)控體系都已經(jīng)能夠做到，方式上以在宿主機(jī)上運(yùn)行agent，進(jìn)行資源數(shù)據(jù)收集、然后上報(bào)為多