銀行容器雲平臺建設的關鍵設計 | 資料

【摘要】容器平臺的建設要考慮場景、技術、系統對接、成本、人員技能等因素，有不小的複雜度。本文從一個最精簡容器平臺所需考慮的各個方面，結合作者的專案實踐，提出供大家參考的建議。

【作者】蔡凱，多年IT從業經歷，曾服務於IBM、HP、微軟等企業，以及全國性股份制商業銀行科技部，具有豐富的軟體開發、系統架構經驗。近年專注於雲端計算PaaS相關領域，對基於容器、微服務架構等開源技術的架構設計和應用有廣泛積累。

目錄

1 銀行建設容器平臺的背景
2 需求分析
3 業務架構
4 關鍵設計
4.1 資源池管理
4.2 網路設計
4.2.1 技術方案選擇
4.2.2 網路拓撲規劃
4.3 映象倉庫
4.4 應用管理
4.4.1 應用編排
4.4.2 生命週期管理
4.5 安全管理
4.5.1 對接安全合規體系
4.5.2 多租戶隔離
4.5.3 應用等級隔離
4.6 監控日誌
4.6.1 監控
4.6.2 日誌
5 總結和建議

1 銀行建設容器平臺的背景

隨著網際網路金融的興起，網際網路企業依託網際網路，特別是移動網際網路為公眾提供越來越多方便快捷、穩定高效的金融類服務，對傳統的銀行業務帶來了很大沖擊。作為應對，傳統銀行也在業務上不斷創新，帶來對IT基礎設施和應用架構方面進行轉型升級的要求。例如為了支撐電商促銷活動對銀行帶來的高峰期海量支付請求，某銀行很早就對支付渠道相關業務應用進行微服務架構改造，由此帶來了容器技術的研究和運用。此銀行的多年實踐證明，採用容器技術平臺很好地支撐了新的業務模式和業務容量。

基於業務發展的需要，和快速進步的金融科技技術，越來越多的傳統銀行在思考自身的網際網路金融戰略、金融雲規劃等。其中重要內容之一，是希望從技術層面更有效地支援業務創新，如微服務架構、更好的靈活性、擴充套件性、高可用性、更高效的業務上線效率等，因此跟上雲端計算技術發展的趨勢，建設並推廣適合自身的基於容器技術的雲平臺是關鍵任務。

2 需求分析

銀行建設容器平臺，不僅需要為基於微服務架構的新業務提供容器化執行和管控平臺之外，還必須非常重視滿足金融行業嚴苛的監管和安全要求。這樣的定位決定了在銀行建設容器平臺除了要具備市場上大多數容器平臺產品的能力，還應該為銀行的特殊監管需求進行定製。

因此制定銀行容器平臺的需求時，建議考慮包括的方面有：

• 管理大規模容器叢集能力，包括：提供容器所需的高可用叢集、資源池管理、網路通訊方案、儲存方案、編排排程引擎、微服務執行框架、映象管理、事件告警、叢集監控和日誌收集等。

• 為滿足金融業務的監管和安全要求，平臺需要考慮應用的高可用性和業務連續性、多租戶安全隔離、不同等級業務隔離、防火牆策略、安全漏洞掃描、映象安全、後臺運維的4A納管、審計日誌；如果容器平臺還對公網提供訪問，那麼還需要考慮訪問鏈路加密、安全證書等。

還有一個重要方面是，銀行的金融雲是一個範圍更大的複雜雲環境，容器平臺通常是這個複雜系統中的一部分，因此容器平臺還要遵從銀行已有IT技術規範和運維要求，例如可能還需要考慮：

• 支援銀行自身的應用釋出體系、持續整合系統、應用建模規範、高可用管理策略

• 對接金融雲底層資源池（例如IaaS），遵從雲端計算資源的統一管理和分配

• 對接或改造容器平臺的網路，以滿足容器平臺中應用與傳統虛擬機器、物理機中舊業務系統的相互通訊，避免或儘可能減少對銀行現有網路管理模式的衝擊

• 對接統一身份驗證、和整個金融雲其它系統採用統一的租戶定義、角色定義、資源配額定義等

• 對接漏洞掃描、集中監控系統、日誌分析系統等已有周邊系統

3 業務架構

基於對容器平臺的需求分析，可以用如下的業務架構圖描述容器平臺應提供的業務能力、以及容器平臺在銀行可能和周邊系統的對接關係：

各業務模組提供的功能，以及可能需要整合、對接的情況是：

4 關鍵設計

以下討論業務架構中各個業務模組的關鍵設計思路。

4.1 資源池管理

容器平臺資源池管理負責容器執行所需的計算、儲存資源申請、分配、容量管理，以及適合的容器網路通訊方案。容器網路方案比較複雜，稍後專門論述，這裡先探討關於計算和儲存資源的管理。

對於計算和儲存資源的申請、分配、容量管理，可能的兩種做法是：

• 按照容量預估，預先為容器平臺分配預測的計算節點、儲存容量的資源，在容器平臺中將這些資源註冊到容器叢集中使用。當需要擴容或刪除某些資源時，重複相應的動作。

• 對接外部的資源管理和供給系統，通常是IaaS系統或者具備資源供給能力的自動化系統，透過呼叫外部系統的介面，容器平臺按需獲取所需的計算和儲存資源。

第一種做法的優勢在於系統簡單，不需要對接外部資源管理系統，適合技術驗證平臺，或容量不需要頻繁變化的情況。對於生產系統或複雜的測試系統，基本上都應該考慮第二種做法，雖然帶來了系統整合的複雜性，但容器平臺可以藉助外部的IaaS等系統，確保所申請的資源的高可用性，例如可以藉助底層IaaS系統的功能，確保容器平臺獲得的宿主機均勻分佈在不同的可用區AZ，這些不同的可用區AZ可能具備不同的供電、網路連線裝置等，通常對應於資料中心不同的物理區域、樓層或樓宇，由此減少某一故障導致大部分甚至全部容器宿主機癱瘓的可能性；同時，第二種做法讓資源申請和獲得無需人工介入，因此能做到容器平臺資源的按需自動申請、彈性擴容。

目前市場上的容器平臺開源技術方案，或商業容器平臺，大多具備了和IaaS系統的整合能力，或者需要開發的相關整合邏輯也並不複雜，例如只需透過IaaS的介面獲取虛擬機器，並用自動化任務在虛擬機器中執行容器平臺新增計算節點的命令，即可完成從資源申請到自動加入容器平臺的完整過程。

4.2 網路設計

4.2.1 技術方案選擇

在資源管理中，網路的管理是比較複雜的。對於容器平臺可能的網路方案，基本上分為以下幾類：

• 原生NAT方案

• 隧道方案（Overlay），代表性的方案有Flannel、Docker Overlay、OVS等

• 路由方案，代表性的方案有Calico、MacVlan

• 自定義網路方案

原生NAT方案中，容器藉助宿主機埠對映、以及在宿主機上配置的iptables規則，對容器的網路資料包進行NAT轉換，再透過宿主機的路由轉發實現不同容器間跨主機的網路通訊。這種方式的優勢是原生支援、簡單、容器例項不需要額外消耗骨幹網路IP地址、也不會增加在宿主機間傳遞資料包的長度；但是缺陷也是明顯的：

• 同一宿主機上不同容器在宿主機上的對映埠必須區分開以避免埠衝突；

• 容器遷移到不同宿主機時，很可能需要改變所對映的宿主機埠，控制比較麻煩；

• 透過NAT通訊使得容器網路資料包在骨幹網上使用的不是自身的IP，給防火牆策略帶來不便；

• 埠對映帶來的網路效能損失，筆者自己的環境下測試結果是，使用NAT方式的容器在進行跨宿主機通訊時，吞吐率只能達到宿主機間吞吐率的1/3。

因此，原生的NAT網路比較適合小規模的功能驗證和試驗環境，網路效能不是重要的考慮因素，測試的場景中也不涉及很多容器遷移、防火牆安全等問題。很顯然，在銀行正式的測試環境、生產環境下，採用原生NAT方案不足以滿足功能、效能和安全監管要求。

隧道方案，也就是Overlay方案，藉助容器宿主機網路，構建出一個對於容器來說三層路由可達虛擬網路。具體做法是透過把容器網路資料包整體封裝放進宿主機網路報文，由宿主機網路轉發到目標容器所在的宿主機，再由目標容器所在的宿主機對報文進行拆解得到容器網路資料包，交給容器網橋，由容器網橋再轉發到目標容器。隧道方案的好處是沒有NAT方案的埠衝突問題、不消耗額外的骨幹網路IP、與現有網路技術不產生衝突因此靈活性大、透過構建不同的VLAN虛擬網路很容易實現網路隔離、網路效能損失比原生NAT方案小，在滿足銀行業務功能和安全監管要求的同時，對效能也有一定的照顧。因此隧道（Overlay）方案目前是應用比較多的選擇，在技術上的可選擇性也最大，方案成熟度也比較高，所以相對其他的方案，隧道方案的實施、定製化、維護的成本比較低。不過事情都有兩面，如果選擇隧道方案，您還是有一些不可迴避問題需要考慮解決：

• 如果容器平臺中執行業務與其它平臺上執行業務需要通訊，則需要配置從容器外部訪問容器的路由，否則容器的地址從容器平臺外部不能直接路由訪問。由於容器動態變化和跨主機遷移的特點，配置從外部訪問容器的路由是一個比較複雜的問題，不僅需要在外部路由器、宿主機路由表中進行配置，還需要將這些配置動作和容器的啟停聯動起來，這需要複雜的SDN能力；

• 由於容器網路資料包在底層網路上傳輸時被封裝在宿主機網路報文中，因此對普通防火牆來說，容器網路資料包的地址不可見。如果需要對容器資料包進行精確的防火牆規則設定，代價很大，幾乎不可行；變通的方法可以考慮把需要進行網路隔離的容器，在啟動時指定所在的VLAN，透過不同的VLAN來實現隔離；

• 由於容器網路資料包需要被封裝在底層宿主機網路報文中，因此會增加底層網路資料包的長度，當您的底層網路也是Overlay網路，或者Overlay的層數較多時，會影響網路資料包承載資料的效率，並且封裝和拆解資料包的次數也會顯著影響網路的傳輸效率，對於效能關鍵的場景，這個問題也需要引起重視。

路由方案透過路由技術從三層或者二層實現跨主機容器互通，沒有NAT，沒有Overlay方案需要的資料包封裝和拆解，每一個容器具有路由可達的IP地址，且可以做到從容器平臺外部路由可達。這種網路方案的好處是效能損失小、外部路由可達、傳統的防火牆仍然能正常發揮作用等。但缺點是：

• IP地址消耗大，如果容器數量規模大，特別是採用微服務架構後，大量的容器IP資源被消耗，且可能出現大量IP衝擊到路由表裡，導致路由效率降低等問題；

• 容器平臺外部對容器網路中網路實體的變化仍不能感知，例如新的容器建立或發生跨主機遷移時，以Calico方案為例，Felix和BGP client模組可以保證容器網路內的路由策略更新，但由於容器平臺外界不能感知容器的變化，外部到此新建立容器的路由則沒辦法被自動建立，仍然需要額外的路由更新工作補充。

再來探討自定義網路方案，本文所提的自定義網路方案泛指標對自身特定需求，而在既有網路技術基礎之上進行改造，或者將不同的網路技術進行整合、打通而形成的特殊方案。例如在某銀行，容器平臺作為整個金融雲平臺的一部分，在設計容器網路時，需要考慮整個金融雲網路管理上的一致性，由此要求容器網路具備和底層宿主機網路相同的網路層級、IP地址規劃、子網劃分規則，並能夠實現容器例項和容器平臺以外的直接路由互通，以便能夠對容器網路複用既有的SDN控制器管理、防火牆、安全漏掃、網路抓包分析工具等的能力。因此該銀行在建設自己容器平臺網路時，對接了IAAS的Neutron+SDN進行統一網路管理，工作原理是：

• 當容器平臺需要為新的租戶分配網路資源時，通知Neutron，由Neutron對接的SDN控制器按照預先定義的規則為容器平臺分配所需的子網和網路地址空間；

• 開發網路驅動，實現CNI介面。當容器平臺建立新的容器例項時，網路驅動呼叫Neutron介面建立port，為容器例項在子網中分配MAC和IP，並把IP繫結到容器網路卡（類似nova-compute的工作），然後通知Neutron容器IP配置成功；

• 容器平臺記錄容器的IP地址，作為進行服務註冊、服務發現、監控服務的基礎；

• Neutron和SDN聯動，完成為容器例項設定相關的路由策略、防火牆策略等。

這種方案的效果即保證網路效率、也能完全融入現有網路管理體系、還能做到完全的SDN聯動，但複雜程度高，定製的成本也比較大，且由於完全基於路由而沒有Overlay，也存在IP地址消耗比較大的問題。

需要宣告以上只是以某個特定銀行的定製方案為例，讀者所在的銀行和企業可能有自己對容器網路的需求，以及自己的技術考慮，因此自定義網路方案的可能性多種多樣，最終實現的能力和代價也差別很大。

如何選擇容器平臺的網路技術方案會相當複雜，涉及技術、場景、人員技能、成本等多方面。容器平臺網路方案直接關係到平臺的容量、效率、實施和運維成本，因此選擇需要充分論證，考慮容器平臺的定位、規模發展、承載的業務場景、對現有網路的影響、對與集中監控系統、安全合規檢查系統整合的影響等，需要認真評估需求、平衡收益和成本。

4.2.2 網路拓撲規劃

除了技術方案，網路拓撲規劃是網路設計的另一個重要方面，不僅涉及網路管理複雜度，還直接關係到安全合規。傳統上銀行科技部門會為不同安全等級的應用劃分不同的網路區，分別提供不同的安全等級保護；也可能會根據執行業務的特點，分為可直接對外提供服務的網路隔離區，和只在內部執行業務處理和資料處理的業務區、資料庫區等。在規劃容器平臺的網路拓撲時，建議保留這些已經成熟並實踐多年的網路區域劃分方法，保持遵守對安全合規的監管要求。

同時，根據對容器平臺的定位和管理策略，容器平臺可能需要在傳統的網路拓撲上做相應的擴充，例如：

• 如果容器平臺是金融雲的一部分，網路拓撲必須支援多租戶的隔離；

• 容器平臺中的容器和宿主機都執行在網路中，容器執行應用屬於業務，而宿主機執行容器屬於資源，建議把容器所在的業務域和宿主機所在的資源域劃分到不同的網路區，分別使用不同的管理和訪問策略，保留足夠的靈活性滿足不同的使用者需求；

• 容器平臺自身執行所需的管理節點、映象倉庫、計算節點可以考慮放到不同的網路區，以滿足它們各自不同的執行要求。例如映象倉庫可能需要提供對公網的服務，以便使用者從公網瀏覽和管理映象、管理節點可能需要執行在支援帶外管理的網路區等。

用下圖總結以上探討的銀行如何規劃容器平臺網路拓撲的內容： 

4.3 映象倉庫

映象倉庫負責儲存和釋出應用的映象部署版本，在功能上並不複雜，但由於監管要求和業務的特殊性，銀行高度關切生產環境的安全性，都要求用於生產釋出的映象版本必須透過嚴格的測試階段，以及嚴密的安全檢查步驟，因此建議對生產環境執行專用的生產映象倉庫；同時，在持續整合越來越普遍的情況下，為了保證開發和測試的方便，我們需要測試映象倉庫。建議生產映象庫和測試映象庫在物理上分開、網路上的連通透過防火牆策略做限制（只開放必須的埠用於映象同步）。

在使用規則上，測試映象倉庫允許隨時的映象上傳和更新，通常都會對接持續整合系統；而對於生產映象倉庫，為了保證映象來源的安全、可控，建議限制為只能從測試映象同步，規定只有在測試映象倉庫中標記為完成測試、經過安全檢查的映象，由有相應許可權的賬號，在經過必要的審批或者滿足一定規則的情況下，從測試映象倉庫中把映象同步到生產映象倉庫。一旦映象進入生產映象倉庫，就被當做正式的生產釋出版本，接下來就按照銀行現有的生產釋出和變更流程，在指定的變更視窗，從生產映象庫中拉取映象進行部署，這樣做也很好地滿足了銀行的安全監管要求。

下圖總結建議的映象倉庫體系、和相關工作流程：

4.4 應用管理

應用管理負責執行基於容器映象的輕量級應用或微服務，提供應用的微服務編排能力、應用全生命週期管理。

4.4.1 應用編排

應用編排的目的是為了給容器平臺上執行的應用進行建模標準化，描述應用執行的資源需求、部署模式、部署引數、執行時動態規則（彈性伸縮、故障遷移等）。目前開源和商用容器平臺都已支援自己的應用編排，例如Kubernetes的yaml檔案方式，但對銀行來說，可能還存在一些不足：

• 對銀行的特定需求支援不足，例如銀行應用的安全等級、部署的網路區等這些特殊資訊的描述；

• 不同的容器編排系統、甚至同一編排系統的不同版本，可能存在編排語法不同、不相容的問題。銀行的應用建模是重要的資產，不能允許由於版本升級、技術改造而導致眾多應用的建模不相容。

因此建議容器平臺自定義應用編排規範，如果容器平臺定位為銀行整體金融雲的一部分，那麼容器平臺的應用編排應相容整體金融雲的應用建模規範，確保金融雲上所有應用建模的一致性。

在用自定義的編排規範對應用進行標準化描述後，需要對底層的容器平臺進行能力擴充定製，對應用編排資訊進行翻譯，變成容器平臺可以理解的資訊，再根據這些資訊對應用進行部署、升級和執行管理。下面的圖描述了應用建模、以及使用應用建模進行部署、升級和執行管理的過程。

4.4.2 生命週期管理

應用全生命週期管理負責應用的上架、部署、升級、下架、支援執行時動態管理策略，還可支援雙活部署、同城災備切換等金融雲高階能力。這部分功能可能需要對接金融雲的應用釋出、高可用部署和切換模組，提供整個金融雲所有應用統一的部署、高可用體驗。在上一節應用編排，我們討論了有關上架、部署、升級、執行管理等，這裡來看應用的高可用部署和切換。

容器平臺可以從例項、服務、應用三個層級，分別實現應用的高可用，分別是：

• 例項級，即容器故障自動恢復；

• 服務級，即服務/微服務的多個例項的跨不同可用區部署；

• 應用級，即應用跨資料中心切換。

從單個執行例項級別，可以採用容器故障自動恢復機制，對發生故障的容器例項進行快速的故障發現、自動遷移和恢復。基本上開源和商業的容器叢集管理系統都支援按照使用者預定義的規則，進行故障檢測和例項恢復。

從單個服務級別，可以把一個服務或微服務的多個容器執行例項，在跨多個可用區中進行分佈部署。在容器平臺在進行資源池管理時，藉助底層IaaS平臺，確保容器宿主機均勻分佈在不同的可用區AZ中。當在容器平臺部署一個服務或微服務的多個容器例項時，儘量把多個容器例項排程執行在處於不同可用區AZ的宿主機上，這可以藉助容器排程策略、以及事先對宿主機加標籤以方便識別所在的可用區來配合完成。

絕大多數情況下，我們都有機會從例項級別、服務級別進行努力，提高應用的高可用性。

現在越來越多的銀行都在建設自己的多地或多中心繫統，或者即有本地私有資料中心，也同時具備雲端的資料中心。如果您有這樣的基礎設施，或有相關的建設目標，那麼您還可以從更高的級別，即從整個應用的級別來考慮高可用性。做法是在多個資料中心，對應用進行多活、或者主備的部署，把業務流量按照合適的比例分發到不同的資料中心進行交易處理。多資料中心部署的一個關鍵問題是交易資料的一致性，由於分散式資料庫在資料一致性上目前並不成熟，分庫分表又會帶來額外的關聯複雜性，因此大多數銀行當前階段選擇起來還很謹慎，而會繼續採用單個集中的主資料庫，加上位於不同資料中心的備庫，之間透過資料庫自身的同步技術、加上底層儲存系統的快速同步，確保備庫和主庫的資料保持一致，在進行資料中心切換時，儘可能地減小資料丟失，即減小RPO。採用主備庫同步的方案，會對網路低延遲有比較高的要求，這限制了不同資料中心間的最遠距離，通常位於同一城市區域、相距數十公里以內是比較可行和普遍的。

4.5 安全管理

安全管理是滿足行業監管要求必須考慮的問題，是銀行建設容器平臺的特殊要求。

安全管理的難點在於涉及面廣，包括系統漏洞、病毒威脅、鏈路加密、攻擊防範、系統訪問許可權上收、操作審計等，此外安全管理面對的安全威脅不斷地發展變化，也增加了防範的技術難度和持續的工作量。同時金融雲和容器自身的特點，在傳統銀行安全管理的基礎上，還增加了多租戶隔離、角色管理、映象安全檢測等新問題。

4.5.1 對接安全合規體系

鑑於安全管理的複雜性，如果在容器平臺中單獨進行安全管理，代價很高；而且安全管理也十分依賴長時間的積累，容器平臺單獨進行安全管理，也難免在一段時間內出現各種安全問題紕漏。因此建議容器平臺在安全管理上直接對接銀行現有的安全管理防範體系，充分利用現有的各類安全工具、手段，在現有安全管理手段的基礎上，按需增加功能應對容器平臺帶來的新需求新問題。這應該是見效快、成本低、風險也比較低的方式。

銀行面對嚴格的行業安全監管要求，現有的安全管理防範體系，包括技術工具、工作流程和指導規範等都已經相當完備，例如系統漏洞掃描、補丁安裝、防病毒系統、SSL和證書申請、WAF、統一身份認證和4A訪問管理、操作日誌審計等。為了利用上這些能力，需要在容器平臺設計，特別是網路方案的設計上，仔細考慮如何才能讓這些工具和手段對容器平臺發揮作用。例如某銀行系統漏洞掃描的方式是由執行在網路中的掃描服務，定期地透過向被掃描目標IP傳送埠檢測報文，分析響應結果來判斷是否存在系統漏洞，做出是否需要安裝補丁或者關閉被掃描目標相關係統服務等決定。為了讓系統漏洞掃描服務能對容器平臺正常工作，那麼在設計網路方案時，讓漏洞掃描服務與容器平臺中的容器IP路由可達就是必須要考慮的問題。

4.5.2 多租戶隔離

如果容器平臺作為金融雲的一部分，並計劃為不同的租戶提供服務，那麼根據租戶對安全的要求，支援不同租戶的隔離也是要考慮的內容。

在之前討論網路拓撲規劃時，建議把不同租戶的容器執行在各自不同的虛擬網路VLAN中，併為不同的VLAN設定必須的防火牆規則、關閉相關的路由來保證不同租戶的業務在網路上隔離。

由於容器共享宿主機核心的特點，如果把不同租戶的容器執行在同一臺宿主機上，租戶可能面臨來自其他租戶容器執行帶來的不利影響，例如：

• 資源競爭導致的效能下降；

• 其他租戶容器應用的bug導致的宿主機核心執行異常，進而導致自己租戶容器的執行故障；

• 潛在的來自其他租戶的惡意容器應用，利用共享核心進行攻擊和竊密。

因此，建議容器平臺為不同的租戶分配各自專屬的、不同的資源池，租戶只能在屬於自己的宿主機上執行自己的容器應用。這雖然導致了資源利用率的降低，但在根本上回避了容器執行依賴共享宿主機核心、隔離性天生不如虛擬機器的侷限，這和主要基於虛擬機器的IaaS平臺對多租戶隔離的做法不同。

4.5.3 應用等級隔離

除了不同租戶間的隔離，即使在同一租戶下，執行不同安全等級的應用，因為容器共享系統核心的特點，應用也面臨其它等級應用的資源爭搶、故障影響等問題。另外，不同等級的應用，往往要求不同級別的執行環境高可用性、安全性，因此在同一租戶下，也應該把不同等級的應用隔離開，分別部署到各自專屬的資源池內。

下面的圖以兩個租戶、分別有不同的安全等級的應用部署為例，描繪應用的部署狀態：

4.6 監控日誌

4.6.1 監控

和安全管理類似，監控體系也在銀行發展多年，特別是針對生產系統的監控、告警體系，根據自身運維的需要，不斷積累、最佳化了多年，大多已經比較完備；圍繞目前的監控體系，也形成了成熟的應急方案、流程，人員技能和經驗也多圍繞既有生產監控系統進行培訓、學習。

因此，如果容器平臺沒有特別的需求，在銀行的生產環境下，建議將容器平臺的監控體系對接目前的集中監控系統，方便運維人員對生產環境的統一監控管理，既有的應急方案、流程、人員技能和經驗都可以得到沿用。

即使容器平臺有不同於傳統的監控需求，例如：

• 容器執行不再關注單個容器例項的增加和消失，而只關注整體服務的可用性；

• 新的業務應用透過輸出標準化日誌，對日誌進行分析提取業務效能資料、成功率。

出現這些不同的需求，也建議用集中監控系統進行展示和告警，只是需要在集中監控系統之外先進行處理，再把處理後的結果對接到集中監控系統。例如，我們不用再在集中監控系統中配置去監控每一個容器例項的IP，而是由容器平臺檢查服務所需要的容器例項數量是否還在允許的最小值以上，只有當例項數量低於接受的最小值，才給集中監控系統傳送告警，其它情況下只需要彙報當前例項數量即可，不在乎例項數量的波動。

在設計具體的監控時，應把監控進行分類，分別處理。具體可分為：

• 應用和服務監控

• 資源監控

• 平臺監控

應用和服務監控關心業務服務的正確工作狀態，這可能需要透過呼叫平臺API、或透過應用日誌分析、特定埠響應等方法來判斷，需要開發一定的邏輯處理，再把結果對接到集中監控。

資源監控主要關注每個宿主機、以及計算節點叢集的整體資源的使用情況，是否需要增加節點擴容等，這一點基本上傳統的監控體系都已經能夠做到，方式上以在宿主機上執行agent，進行資源資料收集、然後上報為多。

平臺的監控關注容器平臺的控制節點、資料庫、提供的服務等是否工作正常，這一點通常開源和商業的容器平臺自身就已提供相應的管理控制檯。如果不介意介面風格的差異，集中監控系統可以直接嵌入或跳轉到容器平臺的管理控制檯；如果為了一致的監控體驗，或者需要進一步的監控和告警定製，就需要開發整合邏輯，透過呼叫容器平臺的API，對獲得的資料進行處理、封裝，再對接到集中監控系統。

4.6.2 日誌

在容器平臺中，日誌大致分為兩類：

• 環境日誌，包括容器執行日誌、宿主機容器引擎日誌、容器平臺管理日誌；

• 應用日誌，指執行在容器中的業務應用在進行業務處理中，對處理過程中的關鍵結果、狀態所進行的記錄。

環境日誌有各自固定的輸出位置，主要用於出現故障時進行運維排查，和容器平臺執行的業務並無直接關係；對於容器平臺，更需要關注、處理的是應用日誌。因為以容器為載體，以分散式方式執行，無論是執行位置、數量等都會隨時發生變化，所以如果不對應用日誌做特別處理，應用日誌會散佈在容器叢集的任意節點上。傳統的方式，即登入到某一個特定的節點上去檢視日誌，已經不能適用於容器平臺中的應用了。

我們必須對應用的日誌進行集中收集，相關的開源方案選擇也比較豐富，例如ELK、Fluentd等，或者直接透過在容器中掛載NFS共享檔案系統，把業務執行的日誌實時寫到共享檔案系統中進行集中收集。

5 總結和建議

容器平臺的建設要考慮場景、技術、系統對接、成本、人員技能等因素，有不小的複雜度。以上各部分從一個最精簡容器平臺所需考慮的各個方面，結合作者的專案實踐，提出供大家參考的建議。

容器技術發展非常迅速，相關的開源社群和廠商都在努力貢獻，新技術層出不窮。同時，微服務框架的功能越來越完備，隨著微服務架構思想不斷普及，不久的將來會有越來越多的新業務基於微服務架構的形式出現，而容器是微服務架構應用的最理想執行環境，這就意味著容器平臺未來的應用場景也是不斷改變、進化和越來越豐富的。

在目前階段，容器平臺的建設是一個不斷改進，迭代積累的過程。一開始可能沒辦法在各個方面都能想得很清楚，不僅在技術方案，更在業務場景、運維方式、安全合規等方面，都需要很多的討論。但不應該懷疑這個大的趨勢，看看Google、Netflix等國際大廠商在容器、微服務上的成功，以及國內的網際網路廠商在容器和微服務上不斷的投入和積累，我們應該相信這個方向並持續地發展下去。近幾年在人民銀行年度的銀行獲獎科技專案中，有關容器技術的專案逐漸增多，也是肯定在這個方向發展的標誌。

技術和市場不會停下來等任何人，如果您想跟上技術的趨勢，請在您的組織內給容器平臺、微服務推廣等工作足夠的信任，投入上從小規模試驗做起，積累經驗後慢慢推廣，隨著技術和和市場的成熟，更多的微服務架構應用執行在容器平臺上，為業務帶來服務能力和效率提升，也為投入帶來應有的回報。