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

2、AGEREF _Toc65359147 h 4 HYPERLINK l _Toc65359148 3 業務架構 PAGEREF _Toc65359148 h 5 HYPERLINK l _Toc65359149 4 關鍵設計 PAGEREF _Toc65359149 h 7 HYPERLINK l _Toc65359150 4.1 資源池管理 PAGEREF _Toc65359150 h 7 HYPERLINK l _Toc65359151 4.2 網絡設計 PAGEREF _Toc65359151 h 8 HYPERLINK l _Toc65359152 4.2.1 技術方案選擇 PAGER

3、EF _Toc65359152 h 8 HYPERLINK l _Toc65359153 4.2.2 網絡拓撲規劃 PAGEREF _Toc65359153 h 12 HYPERLINK l _Toc65359154 4.4.1 應用編排 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、 對接安全合規體系 PAGEREF _Toc65359157 h 17 HYPERLINK l _Toc65359158 4.5.2 多租戶隔離 PAGEREF _Toc65359158 h 17 HYPERLINK l _Toc65359159 4.5.3 應用等級隔離 PAGEREF _Toc65359159 h 18 HYPERLINK l _Toc65359160 4.6 監控日志 PAGEREF _Toc65359160 h 19 HYPERLINK l _Toc65359161 4.6.1 監控 PAGEREF _Toc65359161 h 19 HYPERLINK l _Toc6

5、5359162 4.6.2 日志 PAGEREF _Toc65359162 h 20 HYPERLINK l _Toc65359163 5 總結和建議 PAGEREF _Toc65359163 h 211 銀行建設容器平臺的背景隨著互聯網金融的興起，互聯網企業依托互聯網，特別是移動互聯網為公眾提供越來越多方便快捷、穩定高效的金融類服務，對傳統的銀行業務帶來了很大沖擊。作為應對，傳統銀行也在業務上不斷創新，帶來對IT基礎設施和應用架構方面進行轉型升級的要求。例如為了支撐電商促銷活動對銀行帶來的高峰期海量支付請求，某銀行很早就對支付渠道相關業務應用進行微服務架構改造，由此帶來了容器技術的研究和運用

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

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

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

9、的對接關系：各業務模塊提供的功能，以及可能需要集成、對接的情況是：4 關鍵設計以下討論業務架構中各個業務模塊的關鍵設計思路。4.1 資源池管理容器平臺資源池管理負責容器運行所需的計算、存儲資源申請、分配、容量管理，以及適合的容器網絡通信方案。容器網絡方案比較復雜，稍后專門論述，這里先探討關于計算和存儲資源的管理。對于計算和存儲資源的申請、分配、容量管理，可能的兩種做法是：按照容量預估，預先為容器平臺分配預測的計算節點、存儲容量的資源，在容器平臺中將這些資源注冊到容器集群中使用。當需要擴容或刪除某些資源時，重復相應的動作。對接外部的資源管理和供給系統，通常是IaaS系統或者具備資源供給能力的自動

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

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

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

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

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

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

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

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

18、絡具備和底層宿主機網絡相同的網絡層級、IP地址規劃、子網劃分規則，并能夠實現容器實例和容器平臺以外的直接路由互通，以便能夠對容器網絡復用既有的SDN控制器管理、防火墻、安全漏掃、網絡抓包分析工具等的能力。因此該銀行在建設自己容器平臺網絡時，對接了IAAS的Neutron+SDN進行統一網絡管理，工作原理是：當容器平臺需要為新的租戶分配網絡資源時，通知Neutron，由Neutron對接的SDN控制器按照預先定義的規則為容器平臺分配所需的子網和網絡地址空間；開發網絡驅動，實現CNI接口。當容器平臺創建新的容器實例時，網絡驅動調用Neutron接口創建port，為容器實例在子網中分配MAC和IP，

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

20、的能力和代價也差別很大。如何選擇容器平臺的網絡技術方案會相當復雜，涉及技術、場景、人員技能、成本等多方面。容器平臺網絡方案直接關系到平臺的容量、效率、實施和運維成本，因此選擇需要充分論證，考慮容器平臺的定位、規模發展、承載的業務場景、對現有網絡的影響、對與集中監控系統、安全合規檢查系統集成的影響等，需要認真評估需求、平衡收益和成本。4.2.2 網絡拓撲規劃除了技術方案，網絡拓撲規劃是網絡設計的另一個重要方面，不僅涉及網絡管理復雜度，還直接關系到安全合規。傳統上銀行科技部門會為不同安全等級的應用劃分不同的網絡區，分別提供不同的安全等級保護；也可能會根據運行業務的特點，分為可直接對外提供服務的網絡

21、隔離區，和只在內部運行業務處理和數據處理的業務區、數據庫區等。在規劃容器平臺的網絡拓撲時，建議保留這些已經成熟并實踐多年的網絡區域劃分方法，保持遵守對安全合規的監管要求。同時，根據對容器平臺的定位和管理策略，容器平臺可能需要在傳統的網絡拓撲上做相應的擴充，例如：如果容器平臺是金融云的一部分，網絡拓撲必須支持多租戶的隔離；容器平臺中的容器和宿主機都運行在網絡中，容器運行應用屬于業務，而宿主機運行容器屬于資源，建議把容器所在的業務域和宿主機所在的資源域劃分到不同的網絡區，分別使用不同的管理和訪問策略，保留足夠的靈活性滿足不同的用戶需求；容器平臺自身運行所需的管理節點、鏡像倉庫、計算節點可以考慮放到

22、不同的網絡區，以滿足它們各自不同的運行要求。例如鏡像倉庫可能需要提供對公網的服務，以便用戶從公網瀏覽和管理鏡像、管理節點可能需要運行在支持帶外管理的網絡區等。用下圖總結以上探討的銀行如何規劃容器平臺網絡拓撲的內容：4.3 鏡像倉庫鏡像倉庫負責存儲和發布應用的鏡像部署版本，在功能上并不復雜，但由于監管要求和業務的特殊性，銀行高度關切生產環境的安全性，都要求用于生產發布的鏡像版本必須通過嚴格的測試階段，以及嚴密的安全檢查步驟，因此建議對生產環境運行專用的生產鏡像倉庫；同時，在持續集成越來越普遍的情況下，為了保證開發和測試的方便，我們需要測試鏡像倉庫。建議生產鏡像庫和測試鏡像庫在物理上分開、網絡上的

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

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

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

26、城災備切換等金融云高級能力。這部分功能可能需要對接金融云的應用發布、高可用部署和切換模塊，提供整個金融云所有應用統一的部署、高可用體驗。在上一節應用編排，我們討論了有關上架、部署、升級、運行管理等，這里來看應用的高可用部署和切換。容器平臺可以從實例、服務、應用三個層級，分別實現應用的高可用，分別是：實例級，即容器故障自動恢復；服務級，即服務/微服務的多個實例的跨不同可用區部署；應用級，即應用跨數據中心切換。從單個運行實例級別，可以采用容器故障自動恢復機制，對發生故障的容器實例進行快速的故障發現、自動遷移和恢復。基本上開源和商業的容器集群管理系統都支持按照用戶預定義的規則，進行故障檢測和實例恢復

27、。從單個服務級別，可以把一個服務或微服務的多個容器運行實例，在跨多個可用區中進行分布部署。在容器平臺在進行資源池管理時，借助底層IaaS平臺，確保容器宿主機均勻分布在不同的可用區AZ中。當在容器平臺部署一個服務或微服務的多個容器實例時，盡量把多個容器實例調度運行在處于不同可用區AZ的宿主機上，這可以借助容器調度策略、以及事先對宿主機加標簽以方便識別所在的可用區來配合完成。絕大多數情況下，我們都有機會從實例級別、服務級別進行努力，提高應用的高可用性。現在越來越多的銀行都在建設自己的多地或多中心系統，或者即有本地私有數據中心，也同時具備云端的數據中心。如果您有這樣的基礎設施，或有相關的建設目標，那

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

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

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

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

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

33、不同。4.5.3 應用等級隔離除了不同租戶間的隔離，即使在同一租戶下，運行不同安全等級的應用，因為容器共享系統內核的特點，應用也面臨其它等級應用的資源爭搶、故障影響等問題。另外，不同等級的應用，往往要求不同級別的運行環境高可用性、安全性，因此在同一租戶下，也應該把不同等級的應用隔離開，分別部署到各自專屬的資源池內。下面的圖以兩個租戶、分別有不同的安全等級的應用部署為例，描繪應用的部署狀態：4.6 監控日志4.6.1 監控和安全管理類似，監控體系也在銀行發展多年，特別是針對生產系統的監控、告警體系，根據自身運維的需要，不斷積累、優化了多年，大多已經比較完備；圍繞目前的監控體系，也形成了成熟的應急

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

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