微眾銀行案例｜容器化實踐在金融行業落地面臨的問題和挑戰
本文整理自微眾銀行容器負責人陳廣鎮和李煥 在 Techo 開發者大會雲原生專題的分享內容——微眾容器化實踐。本文主要和大家介紹微眾的容器化實踐，具體分為三個部分：里程碑、實踐之路，以及未來的規劃。
微眾應用容器化項目始於2018年底，我們的生產環境在私有機房上，由於基礎設施的差異，容器管理系統主要走自研路線，基於開源產品訂製。
2019年1月，微眾上線了第一個版本，主要實現多K8s集群管理、以及適配公司現有的基礎架構。
2019年2月，微眾系統接入TKE服務，用於快速構建開發測試環境，我們大部分業務都需要獨立的測試環境，利用騰訊雲強大的伸縮能力可以減少我們很多的環境維護工作。
2019年6月，平台優化了核心的調度邏輯，支援了多業務多DCN共享資源池，提升了私有雲資源交付的效率。
2019年12月，微眾研發了一套統一的通用的運維服務，這套服務收斂過去各式各樣的運維工具，並且增加了金融級的安全管理，優化了K8s執行命令的性能問題。
2020年年初，啟動了全量應用容器化項目，現在已經有超過一半的實例跑在了容器上。其中就包括我們的核心金融系統。
2020年年中，平台開始了2.0的迭代，包括訂製化Harbor、應用畫像、通用Operator API等特性。
未來微眾在容器化上小小的積累通過開源的方式貢獻給社區。
下面部分我們介紹一下容器化實踐中遇到的問題和解決方案。
首先，我們看看傳統虛擬機部署業務的效率問題。容器化之前，在虛擬機和物理機上，應用部署流程非常複雜，新業務上線和擴容慢，交付效率低，資源需要預留。流程無法全自動化。應用缺少統一的規範，平台很難做統一的優化。
在容器上，我們要優化VM應用部署的問題。下面是我們對平台的設計。
首先我們對容器平台的定位是公司級的平台服務，要對所有行內業務都通用；
第二，所有功能都要API服務化，為其他工具系統提供介面；
第三，從VM遷移到容器，能實現快速擴容、縮容；
第四，通過合理的調度，資源利用率得到提升；
第五，重新定義我們的基礎架構，將IAAS層服務化，和PAAS層融合，提高資源的交付效率和交付體驗。
在實施的策略上，主要有兩點，一是必須適配現有的基礎設施和運維體系，在初期需要保持和VM一致的體驗，讓應用無感遷移；二是要穩，金融機構有監管的壓力，必須杜絕大面積不可用的現象出現，系統保持穩定是最起碼的要求。
基於這兩點，我們對kubernetes的能力做了很多的限制和訂製化，後面會詳細講到。
下圖是微眾的容器生態全景圖，最頂層是我們的應用層，包括業務系統、工具系統、中間件和創新應用；
第二層是我們平台的API層，組合下層雲原生的服務，對上層提供訂製化的協議；第三層是容器編排管理層，我們的K8s、prometheus、harbor、我們核心的雲原生應用管理引擎等雲原生產品位於這一層。再往下就是我們的iaas層，最底層是機房、網路、騰訊公有雲等。
容器平台邏輯架構圖，左邊是我們原有的運維管理系統，包括發布系統、CMDB等，這些系統通過WCS API管理容器；通過運維服務，運維容器，包括登陸、查日誌、上傳下載文件等。
每個worker節點上都有運行很多的agent，我們提供了統一的agent管理系統進行管理，限制agent的許可權和審計其操作。安全在我們行業是一個非常重要的課題。
再來看一下容器的網路的實踐。在很多公司上雲的時候都會選擇一些開源的網路插件，假設我們選擇了開源的網路會遇到一些問題，首先，有兩套網路體系，沒辦法做直連，還有很多中間件、資料庫進行容器化。第二，很難做IP固定，因為K8s雲原生是不推薦做IP固定，但是我們必須要做。第三拆包、分包過程中所導致的性能損耗以及不穩定的情況，在我們一些網聯交易的系統裡面耗時非常敏感，不可以接受。
考慮到上述問題，我們選擇了直接使用underlay的網路架構。我們把虛擬機和容器放到了同個網路層面上，這樣一來，容器網路運維就轉化成了網路部門同事熟悉的虛擬機運維，使用相同的防火牆策略。
這裡簡單提一下，公有雲場景下，我們使用vpc將cvm和容器打通。
在微眾的私有雲上，我們選擇了underlay，所以我們自研了適配的網路插件wecni。其工作原理是把容器的虛擬網卡插到了網橋上，然後使用交換機做網關。
由於我們需要固定IP，而IP又是和母機所在的TOR關聯，因此我們實現了ipamd模組記錄了容器、ip、機架的關係，業務應用發版、重啟保持ip不變。
我們生產上還有另一個需求，在DMZ/ECN區，容器需要支援同時連內外網。對此，我們wecni支援單容器多網卡特性，在容器里配置兩塊虛擬網卡，默認出外網，內網使用靜態路由表。
公有雲上我們也希望騰訊雲能早日支援這種Pod級的外網方案。
平台解決完網路問題之後要需要解決調度的問題，K8s原生的調度編排能力無法滿足我們在dcn架構下的高可用部署需求，每組DCN是由一組應用和DB組成的數據單元，每組DCN支援一定容量的客戶，我們的調度策略首要是實現DCN級別的高可用，而K8s的調度只能看到本集群的狀況，數據中心有很多K8s，因此我們開發了一個全局調度服務，要跨K8s集群，跨業務部門的統一服務，能夠精確控制每個子系統在每個DCN實地的數量，也要同時考慮未容器化的vm上的實例。
我們的容器調度編排除了支援了複雜的DCN高可用規則外，還支援基於應用畫像的調度策略。應用畫像系統收集prometheus的動態監控數據、CMDB定義的元數據推送至大數據平台，通過一定的演算法生成應用畫像，對子系統和應用進行打標籤，最後通過親和度、應用優先順序打散相似實例的分布。現在支援應用屬性、監控數據、運維屬性、依賴關係數據的聚合。
下面是關於微眾銀行在容器方面的一些實踐相關的介紹。
首先，介紹微眾的日誌系統。日誌系統由三個模組組成，數據採集模組、數據快取模組、數據處理展示模組，日誌採集模組是通過一個標準Daemonset部署的日誌Agent進行採集，每個業務容器都會將日誌掛載到母機的特定目錄中，日誌Agent採集到數據後將數據上傳到數據快取模組，最終通過數據處理模組統一進行數據的處理和展示。在日誌系統中實現了這樣一些功能，比如有異常展示功能，通過Opentracing協議做異常定位和分析，此外還按照監管的要求，統一進行日誌歸檔。另外還有實時流計算、指標的聚合查詢等功能，方便在出現問題的時候能夠快速定位問題。
接下來是監控模組。在我們微眾銀行有一個統一的標準監控平台，因此，在進行容器化的時候，容器的監控必須要適配現存的這套標準的監控模組，所以，在監控方案做了拆分，主要分成兩部分。第一部分容器指標採集相關的，用Prometheus和Thanos來做數據的聚合和採集，另外，我們還自研了一個模組，通過將容器的監控數據，比如CPU、記憶體、網路指標上傳到統一的監控平台，做成與跟VM一致的監控數據。
接下來再給大家介紹一下容器部署平台。在原生的K8s中，發布的時候需要編輯yaml文件，通過kubectl的操作來將容器部署到集群中。這種發布方式是非常難以運維的，主要存在的問題是：發布的時候存在大量手工操作，容易誤操作；在發布過程無法做發布的模板化和可視化；歷史發布記錄無法追溯、無法審計。為了解決這些問題，我們做了一套容器的部署系統，可以通過這套部署系統來完成容器發布的模板化、可視化、可審計化。容器的部署分成兩部分，第一部分是宿主機的部署，我們主機的同學將初始好系統的容器宿主機登記到資源管理服務中，然後可以通過管理台對這個宿主機機進行K8s的初始化。初始化完之後，在資源池中就存在了可以分配的資源。業務方就可以通過流程管理系統發起一個應用實例的申請，實例分配好以後，將實例資訊回寫到元數據管理系統里，業務同學可以在發布平台中選中對應的實例，調用相應的服務來進行結構化的容器的發布。
接下來是統一的運維平台，與部署類似，通常在定位某個容器的問題的時候，需要通過kubectl exec的方式完成。這樣的問題是，kubectl 許可權過高，同時登陸到容器中時可能會有誤操作，從而引發新的問題。為了解決這些問題，我們做了一個統一的運維平台。首先，我們封裝了一個類似於kubectl的客戶端，提供文件的上傳、下載，快速拉起一個容器，調試某個容器等功能。這個客戶端可以通過統一運維平台接入到K8s中，在運維平台中，我們可以收斂所有對容器的運維操作，可以審計、過濾在容器中 執行的命令。同時，我們在工具中封裝大量的高頻操作的命令，讓工具更方便易用。因為金融安全的要求，容器是默認關閉特權模式的。在定位某些問題時，可以通過運維平台有計劃地放開一些特權，讓業務同學可以快速定位相關問題。
接下來介紹一些複雜應用的容器化，比如PaaS應用的容器化。普通業務應用大部分是是無狀態的應用，非常容易進行容器化。但是如果PaaS應用跟普通業務應用有很大區別，很多PaaS應用的組件之間會有複雜上下游依賴關係，增加了容器化複雜性。這裡我們以Redis為例來介紹PaaS應用的容器化。微眾的Redis主要有管理台、Observer、Proxy、Cluster等幾個模組。管理台主要負責整個集群的管理，負責發起集群的擴縮容，修改集群的配置等。Observer負責觀察集群的狀態，Proxy提供了訪問鑒權和熔斷、降級服務等工作，Cluster是負責KV存儲的模組。在對Redis發起擴容的時候，首先要通過管理台進行發起，調用WCS API的服務，WCS會通過操作K8s，增加對應服務副本數，等相對應的容器啟動完成後，會將實例資訊通知管理台，管理台感知到這個新增的實例之後，就會把這個實例的資訊下發至Proxy，Proxy就可以把接入流量打到新的實例上去。
接下來是我們在基礎架構上的容器服務化的工作。之前，在申請一個應用實例往往要做大量工作，要申請一個VM、劃分資源、LB的配置工作、申請網路策略，最終才能部署應用，交付業務使用。在容器化初期，我們將前面的申請VM和劃分資源這兩步合併了，後面的工作還是需要做。在進一步優化之後，我們的目標是將把申請網路策略，申請VIP等工作全部做成自動化，這樣用戶在申請資源後就可以使用，不需要再另外關注防火牆、VIP這些問題。
以上簡單介紹微眾在容器實踐上的一些工作，接下來講一下我們在實踐過程中遇到的一些風險和問題，以及還有未來的規劃。
我們遇到的主要問題歸了幾類，主要有：
- 安全問題。Docker和K8s會不可避免地存在漏洞，每次漏洞修復都要大規模升級集群，每次升級有可能對上面運行的容器造成影響，對K8s的運維是非常大的壓力。因此，要定時評估，盡量將多個安全漏洞和Feature進行合併，定期升級軟體版本。另外就是，特權模式的管理，要通過管理的方式來保證容器安全的管理。
- 資源隔離。K8s裡面，磁碟IO的隔離做得還不是非常好，我們在生產環境中遇到多次，某個容器高IO導致同宿主機機另外一個容器的故障。這些問題的解決方案是，需要把一些IO敏感和IO不敏感的部署調度到同一個母機上，減少這些影響。同時還需要調研IO隔離技術，比如Cgroup2等
- 底層兼容的問題，比如，我們在生產環境的OS內核是3.10版本的，在K8s的有些版本會導致記憶體泄漏的問題，導致容器的OOM。需要定時關注社區有沒有相關介紹，定時升級版本
- 數據丟失的風險。K8s用ETCD來存取數據，對數據的備份、故障恢復要做多做預防工作。我們會對ETCD的數據進行多重備份，同時進行跨IDC多地高可用部署，來保證數據的可用性。
- 故障影響。比如在生產環境我們遇到過宿主機失聯一段時間後重新恢復連接，這時K8s會驅逐容器，大量的關閉操作導致宿主機CPU高，導致聯機交易受到影響。需要有快速介入和恢復的能力
最後，是我們微眾容器平台的規劃。我們現在所做的工作更多還是在推動銀行系統去做容器化，未來我們會更多擁抱雲原生的東西，在CI/CD、微服務、動態擴縮容等方面進行努力，同時，也會把我們這些小小的積累通過開源的方式回饋給社區。
總之來說，在容器化這條道路上，我相信，只要積極擁抱雲原生，一定會有一個光明的未來，謝謝大家！
微眾容器化實踐 PPT 下載方式，請在騰訊雲原生後台回復關鍵字「微眾」獲取。
【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多乾貨！！
