本文整理自微眾銀行容器負責人陳廣鎮和李煥 在 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 下載方式，請在騰訊云原生后臺回復關鍵字“微眾”獲取，
【騰訊云原生】云說新品、云研新術、云游新活、云賞資訊，掃碼關注同名公眾號，及時獲取更多干貨！！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/247113.html
標籤：其他
上一篇：Nginx安裝，開箱即用？