本文整理自**微眾銀行容器負責人陳廣鎮和李煥** 在 Techo 開發者大會雲原生專題的分享內容——微眾容器化實踐。本文主要和大家介紹微眾的容器化實踐，具體分為三個部分：**里程碑、實踐之路，以及未來的規劃**。

![img](https://main.qcloudimg.com/raw/c54acc1ea1ac480b794da31d5e362d25.png)

微眾應用容器化專案始於2018年底，我們的生產環境在私有機房上，由於基礎設施的差異，容器管理系統主要走自研路線，基於開源產品定製。

2019年1月，微眾上線了第一個版本，主要實現多K8s叢集管理、以及適配公司現有的基礎架構。

2019年2月，微眾系統接入TKE服務，用於快速構建開發測試環境，我們大部分業務都需要獨立的測試環境，利用騰訊雲強大的伸縮能力可以減少我們很多的環境維護工作。

2019年6月，平臺最佳化了核心的排程邏輯，支援了多業務多DCN共享資源池，提升了私有云資源交付的效率。

2019年12月，微眾研發了一套統一的通用的運維服務，這套服務收斂過去各式各樣的運維工具，並且增加了金融級的安全管理，最佳化了K8s執行命令的效能問題。

2020年年初，啟動了全量應用容器化專案，現在已經有超過一半的例項跑在了容器上。其中就包括我們的核心金融系統。

2020年年中，平臺開始了2.0的迭代，包括定製化Harbor、應用畫像、通用Operator API等特性。

未來微眾在容器化上小小的積累透過開源的方式貢獻給社群。

![img](https://main.qcloudimg.com/raw/cce789ad70c3b51605eb1536e8f2d92e.png)

下面部分我們介紹一下容器化實踐中遇到的問題和解決方案。

![img](https://main.qcloudimg.com/raw/20435a5537e7445605fa536b23225bfc.png)

首先，我們看看傳統虛擬機器部署業務的效率問題。容器化之前，在虛擬機器和物理機上，應用部署流程非常複雜，新業務上線和擴容慢，交付效率低，資源需要預留。流程無法全自動化。應用缺少統一的規範，平臺很難做統一的最佳化。

![img](https://main.qcloudimg.com/raw/6534aa93d08c67628ec8a4e1c1ee327a.png)

在容器上，我們要最佳化VM應用部署的問題。下面是我們對平臺的設計。

首先我們對容器平臺的定位是公司級的平臺服務，要對所有行內業務都通用；

第二，所有功能都要API服務化，為其他工具系統提供介面；

第三，從VM遷移到容器，能實現快速擴容、縮容；

第四，透過合理的排程，資源利用率得到提升；

第五，重新定義我們的基礎架構，將IAAS層服務化，和PAAS層融合，提高資源的交付效率和交付體驗。

在實施的策略上，主要有兩點，一是必須適配現有的基礎設施和運維體系，在初期需要保持和VM一致的體驗，讓應用無感遷移；二是要穩，金融機構有監管的壓力，必須杜絕大面積不可用的現象出現，系統保持穩定是最起碼的要求。

基於這兩點，我們對kubernetes的能力做了很多的限制和定製化，後面會詳細講到。

![img](https://main.qcloudimg.com/raw/041cc8f91eb175c3aebd7736d4c127c2.png)

下圖是微眾的容器生態全景圖，最頂層是我們的應用層，包括業務系統、工具系統、中介軟體和創新應用；

第二層是我們平臺的API層，組合下層雲原生的服務，對上層提供定製化的協議；第三層是容器編排管理層，我們的K8s、prometheus、harbor、我們核心的雲原生應用管理引擎等雲原生產品位於這一層。再往下就是我們的iaas層，最底層是機房、網路、騰訊公有云等。

![img](https://main.qcloudimg.com/raw/f962778f5a1edf47a2bba5ce9bd0de4b.png)

容器平臺邏輯架構圖，左邊是我們原有的運維管理系統，包括髮布系統、CMDB等，這些系統透過WCS API管理容器；透過運維服務，運維容器，包括登陸、查日誌、上傳下載檔案等。

每個worker節點上都有執行很多的agent，我們提供了統一的agent管理系統進行管理，限制agent的許可權和審計其操作。安全在我們行業是一個非常重要的課題。

![img](https://main.qcloudimg.com/raw/0774886e5753de45f03f4773c3a32ee6.png)

再來看一下容器的網路的實踐。在很多公司上雲的時候都會選擇一些開源的網路外掛，假設我們選擇了開源的網路會遇到一些問題，首先，有兩套網路體系，沒辦法做直連，還有很多中介軟體、資料庫進行容器化。第二，很難做IP固定，因為K8s雲原生是不推薦做IP固定，但是我們必須要做。第三拆包、分包過程中所導致的效能損耗以及不穩定的情況，在我們一些網聯交易的系統裡面耗時非常敏感，不可以接受。

![img](https://main.qcloudimg.com/raw/e6e1a52078792361701318d8511a6697.png)

考慮到上述問題，我們選擇了直接使用underlay的網路架構。我們把虛擬機器和容器放到了同個網路層面上，這樣一來，容器網路運維就轉化成了網路部門同事熟悉的虛擬機器運維，使用相同的防火牆策略。

這裡簡單提一下，公有云場景下，我們使用vpc將cvm和容器打通。

![img](https://main.qcloudimg.com/raw/c05f39b254454f4bf59651deea527fc9.png)

在微眾的私有云上，我們選擇了underlay，所以我們自研了適配的網路外掛wecni。其工作原理是把容器的虛擬網路卡插到了網橋上，然後使用交換機做閘道器。

由於我們需要固定IP，而IP又是和母機所在的TOR關聯，因此我們實現了ipamd模組記錄了容器、ip、機架的關係，業務應用發版、重啟保持ip不變。

我們生產上還有另一個需求，在DMZ/ECN區，容器需要支援同時連內外網。對此，我們wecni支援單容器多網路卡特性，在容器裡配置兩塊虛擬網路卡，預設出外網，內網使用靜態路由表。

公有云上我們也希望騰訊雲能早日支援這種Pod級的外網方案。

![img](https://main.qcloudimg.com/raw/19d82f056cf7fe2a385f805e419b715f.png)

平臺解決完網路問題之後要需要解決排程的問題，K8s原生的排程編排能力無法滿足我們在dcn架構下的高可用部署需求，每組DCN是由一組應用和DB組成的資料單元，每組DCN支援一定容量的客戶，我們的排程策略首要是實現DCN級別的高可用，而K8s的排程只能看到本叢集的狀況，資料中心有很多K8s，因此我們開發了一個全域性排程服務，要跨K8s叢集，跨業務部門的統一服務，能夠精確控制每個子系統在每個DCN實地的數量，也要同時考慮未容器化的vm上的例項。![img](https://main.qcloudimg.com/raw/bc4f1556a46450eea4df2eace9232024.png)

我們的容器排程編排除了支援了複雜的DCN高可用規則外，還支援基於應用畫像的排程策略。應用畫像系統收集prometheus的動態監控資料、CMDB定義的後設資料推送至大資料平臺，透過一定的演算法生成應用畫像，對子系統和應用進行打標籤，最後透過親和度、應用優先順序打散相似例項的分佈。現在支援應用屬性、監控資料、運維屬性、依賴關係資料的聚合。

![img](https://main.qcloudimg.com/raw/edde73ad9c5a17f5b4cf93bb174593cb.png)

下面是關於微眾銀行在容器方面的一些實踐相關的介紹。

首先，介紹微眾的日誌系統。日誌系統由三個模組組成，資料採集模組、資料快取模組、資料處理展示模組，日誌採集模組是透過一個標準Daemonset部署的日誌Agent進行採集，每個業務容器都會將日誌掛載到母機的特定目錄中，日誌Agent採集到資料後將資料上傳到資料快取模組，最終透過資料處理模組統一進行資料的處理和展示。在日誌系統中實現了這樣一些功能，比如有異常展示功能，透過Opentracing協議做異常定位和分析，此外還按照監管的要求，統一進行日誌歸檔。另外還有實時流計算、指標的聚合查詢等功能，方便在出現問題的時候能夠快速定位問題。

![img](https://main.qcloudimg.com/raw/40849f64e4c300de84d0753e22c742c6.png)

接下來是監控模組。在我們微眾銀行有一個統一的標準監控平臺，因此，在進行容器化的時候，容器的監控必須要適配現存的這套標準的監控模組，所以，在監控方案做了拆分，主要分成兩部分。第一部分容器指標採集相關的，用Prometheus和Thanos來做資料的聚合和採集，另外，我們還自研了一個模組，透過將容器的監控資料，比如CPU、記憶體、網路指標上傳到統一的監控平臺，做成與跟VM一致的監控資料。

![img](https://main.qcloudimg.com/raw/061c2695823caeeca92535ba83034870.png)

接下來再給大家介紹一下容器部署平臺。在原生的K8s中，釋出的時候需要編輯yaml檔案，透過kubectl的操作來將容器部署到叢集中。這種釋出方式是非常難以運維的，主要存在的問題是：釋出的時候存在大量手工操作，容易誤操作；在釋出過程無法做釋出的模板化和視覺化；歷史釋出記錄無法追溯、無法審計。為了解決這些問題，我們做了一套容器的部署系統，可以透過這套部署系統來完成容器釋出的模板化、視覺化、可審計化。容器的部署分成兩部分，第一部分是宿主機的部署，我們主機的同學將初始好系統的容器宿主機登記到資源管理服務中，然後可以透過管理臺對這個宿主機機進行K8s的初始化。初始化完之後，在資源池中就存在了可以分配的資源。業務方就可以透過流程管理系統發起一個應用例項的申請，例項分配好以後，將例項資訊回寫到後設資料管理系統裡，業務同學可以在釋出平臺中選中對應的例項，呼叫相應的服務來進行結構化的容器的釋出。

![img](https://main.qcloudimg.com/raw/9578a48e7bc2a268cb55b430f18e61ee.png)

接下來是統一的運維平臺，與部署類似，通常在定位某個容器的問題的時候，需要透過kubectl exec的方式完成。這樣的問題是，kubectl 許可權過高，同時登陸到容器中時可能會有誤操作，從而引發新的問題。為了解決這些問題，我們做了一個統一的運維平臺。首先，我們封裝了一個類似於kubectl的客戶端，提供檔案的上傳、下載，快速拉起一個容器，除錯某個容器等功能。這個客戶端可以透過統一運維平臺接入到K8s中，在運維平臺中，我們可以收斂所有對容器的運維操作，可以審計、過濾在容器中 執行的命令。同時，我們在工具中封裝大量的高頻操作的命令，讓工具更方便易用。因為金融安全的要求，容器是預設關閉特權模式的。在定位某些問題時，可以透過運維平臺有計劃地放開一些特權，讓業務同學可以快速定位相關問題。

![img](https://main.qcloudimg.com/raw/be38f77c706cf3c399a626bd14dfc733.png)

接下來介紹一些複雜應用的容器化，比如PaaS應用的容器化。普通業務應用大部分是是無狀態的應用，非常容易進行容器化。但是如果PaaS應用跟普通業務應用有很大區別，很多PaaS應用的元件之間會有複雜上下游依賴關係，增加了容器化複雜性。這裡我們以Redis為例來介紹PaaS應用的容器化。微眾的Redis主要有管理臺、Observer、Proxy、Cluster等幾個模組。管理臺主要負責整個叢集的管理，負責發起叢集的擴縮容，修改叢集的配置等。Observer負責觀察叢集的狀態，Proxy提供了訪問鑑權和熔斷、降級服務等工作，Cluster是負責KV儲存的模組。在對Redis發起擴容的時候，首先要透過管理臺進行發起，呼叫WCS API的服務，WCS會透過操作K8s，增加對應服務副本數，等相對應的容器啟動完成後，會將例項資訊通知管理臺，管理臺感知到這個新增的例項之後，就會把這個例項的資訊下發至Proxy，Proxy就可以把接入流量打到新的例項上去。

![img](https://main.qcloudimg.com/raw/5e22e3ec87dce8b381c8dc00755cdccb.png)

接下來是我們在基礎架構上的容器服務化的工作。之前，在申請一個應用例項往往要做大量工作，要申請一個VM、劃分資源、LB的配置工作、申請網路策略，最終才能部署應用，交付業務使用。在容器化初期，我們將前面的申請VM和劃分資源這兩步合併了，後面的工作還是需要做。在進一步最佳化之後，我們的目標是將把申請網路策略，申請VIP等工作全部做成自動化，這樣使用者在申請資源後就可以使用，不需要再另外關注防火牆、VIP這些問題。

![img](https://main.qcloudimg.com/raw/0d316fbcb7ae7d4a838f15c4a5b728d6.png)

以上簡單介紹微眾在容器實踐上的一些工作，接下來講一下我們在實踐過程中遇到的一些風險和問題，以及還有未來的規劃。

我們遇到的主要問題歸了幾類，主要有：

1. **安全問題。**Docker和K8s會不可避免地存在漏洞，每次漏洞修復都要大規模升級叢集，每次升級有可能對上面執行的容器造成影響，對K8s的運維是非常大的壓力。因此，要定時評估，儘量將多個安全漏洞和Feature進行合併，定期升級軟體版本。另外就是，特權模式的管理，要透過管理的方式來保證容器安全的管理。
2. **資源隔離。**K8s裡面，磁碟IO的隔離做得還不是非常好，我們在生產環境中遇到多次，某個容器高IO導致同宿主機機另外一個容器的故障。這些問題的解決方案是，需要把一些IO敏感和IO不敏感的部署排程到同一個母機上，減少這些影響。同時還需要調研IO隔離技術，比如Cgroup2等
3. **底層相容的問題**，比如，我們在生產環境的OS核心是3.10版本的，在K8s的有些版本會導致記憶體洩漏的問題，導致容器的OOM。需要定時關注社群有沒有相關介紹，定時升級版本
4. **資料丟失的風險**。K8s用ETCD來存取資料，對資料的備份、故障恢復要做多做預防工作。我們會對ETCD的資料進行多重備份，同時進行跨IDC多地高可用部署，來保證資料的可用性。
5. **故障影響**。比如在生產環境我們遇到過宿主機失聯一段時間後重新恢復連線，這時K8s會驅逐容器，大量的關閉操作導致宿主機CPU高，導致聯機交易受到影響。需要有快速介入和恢復的能力

![img](https://main.qcloudimg.com/raw/2b73ec6eb5c6f64aa19c0ffd3bfd7ba2.png)

最後，是我們微眾容器平臺的規劃。我們現在所做的工作更多還是在推動銀行系統去做容器化，未來我們會更多擁抱雲原生的東西，在CI/CD、微服務、動態擴縮容等方面進行努力，同時，也會把我們這些小小的積累透過開源的方式回饋給社群。

![img](https://main.qcloudimg.com/raw/35080177a457fd812820596c33cbb014.png)

總之來說，在容器化這條道路上，我相信，只要積極擁抱雲原生，一定會有一個光明的未來，謝謝大家！

**微眾容器化實踐 PPT 下載方式**，**請在騰訊雲原生後臺回覆關鍵字“微眾”獲取**。

微眾銀行案例｜容器化實踐在金融行業落地面臨的問題和挑戰

相關文章