摘要：在華為開發者大會（Cloud）2021上，工商銀行Paas雲*台架構師沈一帆發表了《工商銀行多k8s叢集管理及容災實踐》主題演講，分享了工商銀行使用多雲容器編排引擎Karmada的落地實踐過程。
本文分享自華為雲社群《Karmada | 工商銀行多k8s叢集管理及容災實踐》，原文作者：技術火炬手。
在華為開發者大會（Cloud）2021上，工商銀行Paas雲*台架構師沈一帆發表了《工商銀行多k8s叢集管理及容災實踐》主題演講，分享了工商銀行使用多雲容器編排引擎Karmada的落地實踐過程。
演講主要包含4個方面的内容：
1）工行雲*台現狀
2）業界多叢集管理方案及選型
3）為什麼選擇Karmada?
4）落地情況及未來展望
*幾年網際網路的崛起，對金融行業的金融模式及服務模式都産生了巨大的沖擊，這令我們不得不做出一些巨大的革新。同時從現在的角度來看，銀行業務系統入雲已是大勢所趨，截止目前，工商銀行已形成了以基礎設施雲、應用*台雲、金融生态雲以及比較有工行特色的分行雲4個子產品，組成了我們整體的雲*台架構。
工商銀行雲*台的整體架構
采用了業界比較領先的雲産品和主流開源技術，在此基礎上結合了我們一些金融的業務場景，進行了深度化定制。
基礎設施雲：基于華為雲Stack8.0産品結合營運運維需求進行客戶化定制，建構新一代基礎設施雲。
應用*台雲：通過引入開源容器技術Docker、容器叢集排程技術Kubernetes等，自主研發建設應用*台雲。
上層應用方案：基于HaProxy、Dubbo、ElasticSerch等建立負載均衡、微服務、全息監控、日志中心等周邊配套雲生态。
在容器雲方面，工行的金融雲成效也是非常大的，首先展現在它的入雲規模大，截至目前應用*台雲容器規模超20萬，業務容器占到55,000個左右，整體的一些核心業務都已入容器雲内部。除了在同業的入雲規模最大之外，我們的業務場景涉及非常廣泛，一些核心的應用，核心的銀行業務系統，包括個人金融體系的賬戶，快捷支付、線上管道、紀念币預約等，這些核心的業務應用也已容器化部署；另外，我們的一些核心技術支撐類應用如MySQL，還有一些中間件以及微服務架構，這一類核心支撐類應用也已入雲；此外，一些新技術領域，包括物聯網、人工智能、大資料等。
當越來越多的核心業務應用入雲之後，對我們最大的挑戰是容災以及高可用，在這方面我們也做了很多實踐：
1）雲*台支援多層次故障保護機制，確定同一業務的不同執行個體會均衡分發到兩地三中心的不同資源域，確定單個存儲、單個叢集甚至單個資料中心發生故障時，不會影響業務的整體可用性。
2）在故障情況下，雲*台通過容器重新開機及自動漂移，實作故障的自動恢複。
在整體容器雲實踐下，我們也遇到了一些問題，其中比較突出的是 pass層容器層的多叢集的現狀。現在工行内部整體的k8s總數，k8s叢集的總數已*百個，主要的原因有4個：
1）叢集種類多：剛剛也說了我們的業務場景非常的廣泛，比如GPU要有不同支援GPU的裝置，一些中間件，資料庫它對底層的網絡容器存儲的需求是不同的，那勢必會産生不同的解決方案，是以我們需要為不同的業務場景定制不同叢集。
2）受到k8s本身性能的限制，包括scheduler、 etcd 、API server等一些性能瓶頸，每一個叢集也有它數量的上限。
3）業務擴充非常快。
4）故障域分區多，我們兩地三中心的架構至少有三個DC,每個DC内部還有不同的網絡區域，通過防火牆進行隔離, 這樣的倍乘關系，中間就會産生很多叢集故障域的分布。
基于以上4點，針對目前的現狀，我們現有的解決方案還是依靠容器雲的雲管*台，通過雲管*台管理這些多k8s叢集，另外上層的業務應用需要自主選擇它的叢集，包括它需要的偏好、網絡、區域等，去選擇它具體的某一個k8s叢集。在選擇到k8s叢集之後，我們内部是通過故障率進行自動打散的排程。
但現有的解決方案對上層應用還是暴露出非常多的問題：
1）對上層應用來說，它可能上了容器雲比較關心的一個部分，就是我們具有在業務峰值的過程中自動伸縮的能力，但自動伸縮現在隻是在叢集内部，沒有整體的跨叢集自動伸縮的能力。
2）無跨叢集自動排程能力，包括排程的能力可能都是在叢集内部，應用需要自主的選擇具體的叢集
3）叢集對上層使用者不透明
4）無跨叢集故障自動遷移能力。我們還是主要依靠兩地三中心架構上副本的備援，那麼在故障恢複的自動化恢複過程中，這一塊的高可用能力是有缺失的。
基于目前的現狀，我們定下了一些目标，對業界的一些方案進行整體的技術選型，總共分為5個子產品：
為什麼希望它是一個具有一定社群支援度的開源項目，主要是三點的考慮：
1）希望整體方案是企業内部自主可控的，這點也是開源的一大益處
2）不希望花費更多的能力
3）為什麼不把排程以及故障恢複的能力全部內建到剛剛的雲管*台。這部分是我們希望整體的多叢集管理子產品，從雲管*台中隔離出來，下沉到下面的一個多叢集管理子產品。
基于以上這些目标，我們進行社群解決方案的一些調研。
我們調研的第一個是之前比較火的一個叢集聯邦federation項目， federation整體是分v1和v2的版本，我們去調研的時候，那個時候已經主要是v2也就是Kubefed。
Kubefed本身也能解決一部分問題，它具有叢集生命周期管理、Override以及基礎排程的能力，但對我們來說它有幾點緻命的硬傷，目前還無法滿足我們的需求：
1）排程層面是非常基礎的一個排程能力，他們也不準備在排程方面花費更大的精力支援自定義排程，不支援按資源餘量排程。
2）第二點也是比較為人所诟病的，它本身不支援原生k8s對象，我要在它的管理叢集中使用它新定義的CRD，對于我們已經使用了這麼久的k8s原生資源對象的上層應用，雲管*台本身對接API方面，我們也需要重新進行開發，這部分成本是非常大的。
3）它基本不具備故障自動遷移能力
我們調研的第二個項目是RHACM，該項目主要由紅帽和 IBM主導，整體調研下來，發現它的功能是比較健全的，包括我們剛剛所提的能力也是具備的，而且它上層應用application層對于對使用者那一層的能力比較靠*雲管*台這樣一個定位，但它僅僅支援Openshift，對于我們已經存量有這麼多的k8s叢集來說，改造成本非常大，而且太重了。而在我們進行研究的時候，它還沒有開源，社群的整體支援力度是不夠的。
當時我們和華為交流到了多叢集管理的一個現狀以及痛點，包括對社群聯邦類項目的讨論，我們雙方也非常希望能夠在這方面革新，下圖為Karmada的功能視圖：
Karmada功能視圖
從它整體功能視圖及規劃來看，和我們上文提到的目标非常契合，它有叢集整體的生命周期管理、叢集注冊、多叢集伸縮、多叢集排程、整體統一的API、底層标準API支援，它都是CNI/CSI在它整體功能視圖裡，包括上層的應用、對Istio、Mash、CI/CD等都有整體規劃上的考慮。是以基于整體思路，它的功能與我們非常契合，工行也決定投入到這個項目中來，跟華為和我們很多的項目夥伴共建Karmada項目，并把它回饋到我們社群整體。
在我個人的了解上，它有以下優勢：
1）Karmada以類k8s的形式部署，它有API Server、Controller Manager等，對我們已經擁有存量那麼多k8s叢集的企業來說，改造成本是比較小的，我們隻需在上面部署一個管理叢集即可
2）Karmada-Controller-Manager管理包括cluster、policy、binding、works等多種CRD資源作為管理端資源對象，但是它沒有侵入到原生的我們想要部署的那些k8s原生資源對象。
3）Karmada僅管理資源在叢集間的排程，子叢集内配置設定高度自治
Karmada整體的Resources是如何進行分發的？
第一步，叢集注冊到Karmada
第二步，定義Resource Template
第三步，制定分發政策Propagation Policy
第四步，制定Override政策
第五步，看Karmada幹活
下圖為整體的下發流程：
當我們定義了deployment之後，它通過 Propagation Policy進行比對，然後它就會産生一個綁定關系，就是Propagation Binding，然後再通過一個 override的一個policy，就産生了每一個works。這個works其實就是在子叢集中各個資源對象的一個封裝。在這裡我覺得比較重要的是propagation以及workers機制。
首先我們定義的是 Propagation的Policy，可以看到整體yaml得話，我們先定了一個比較簡單的政策，選擇了一個cluster，它叫member 1; 第二個就是我需要這條政策到底比對哪些K8s resource template，它比對的是我們定義了一個namespace為default的nginx deployment。它除了支援Cluster的親和性之外，還支援叢集容忍，按叢集标簽、故障域分發。
當定義完Propagation Policy之後，之前定義的想要下發的K8s resource template會自動跟它進行比對，比對之後，deployment會被分發到比如說ABC三個叢集，這樣就跟ABC三個叢集産生了綁定，這個綁定關系就是Resource Bindding。
Resource Bindding整體的yaml可能就是你選擇的一個cluster，在這裡就是member 1這樣一個cluster，現在整個Resource Bindding是支援cluster和namespace兩種級别的，這兩種級别相當于對應了不同的場景，namespace級别是當一個叢集内部是用namespace做租戶隔離時，可能Resource Bindding用的namespace的 scope。還有一個cluster場景，就是整個子叢集都是給一個人用的，給一個租戶用的，我們直接用Cluster Resource Bindding綁定即可。
在我們已經建立了Propagation Bindding之後，那work是怎麼進行分發的？
當Propagation Bindding産生了之後，比如産生了ABC三個叢集，這裡的1：m就是指這三個叢集。找到這三個叢集之後，Bindding Controller就會工作，然後去産生基于 resource template以及你的綁定關系，去産生具體的works對象，works對象整體就是具體的子叢集中resource的封裝，那麼同時 works 的一個status有一個子叢集resource的回報，可以看到整個work yaml，可以看到manifests下面就是整體的一個子叢集，具體已經override過，具體要分發到子叢集裡面的整體的一個deployment yaml都在這裡了，是以說它隻是一個resource的封裝。
工行在具體使用與驗證之後，發現Karmada有以下幾點優勢：
1）資源排程
自定義跨叢集排程政策
對上層應用透明
支援兩種資源綁定排程
2）容災
動态binding調整
按照叢集标簽或故障域自動分發資源對象
3）叢集管理
支援叢集注冊
全生命周期管理
統一标準的API
4）資源管理
支援k8s原生對象
works支援子叢集資源部署狀态擷取
資源對象分發既支援pull也支援push方式
首先我們看下Karmada其中的兩個功能怎麼去納管叢集和資源下發？
目前為止工行的測試環境中Karmada已經對存量叢集進行了一些納管，在對未來規劃方面，一個比較關鍵的點是如何跟我們整體雲*台進行內建。
在這方面我們希望之前提到的多叢集管理、跨叢集排程、跨叢集伸縮、故障恢複以及資源整體視圖方面都全部下沉到Karmada這樣一個控制*面。
對于上層的雲管*台，我們更注重它對使用者業務的管理，包括使用者管理、應用管理、進項管理等，也包括由Karmada衍生出來的比如說Policy定義在雲*台上。上圖比較簡略，具體的雲*台可能還要連一根線到每一個k8s叢集，比如pod在哪個node上，Karmada的*面可能是不關心的，但具體要知道pod位置類的資訊，可能還要從k8s的子叢集擷取，這個也可能是我們後面內建中需要去解決的問題，當然這也是符合Karmada本身的設計理念，它是不需要關心具體的pod在k8s子叢集的哪個位置。
對于跨叢集排程方面，Karmada已經支援了上文提到的故障域打算、應用偏好、權重對比。但是我們希望它也能夠根據叢集的資源與量去進行排程，這樣不會産生各個子叢集當中資源不均衡的狀态。雖然它暫時是沒有實作的，但它的一個CRD叫cluster， cluster有一個狀态資訊，這個狀态資訊裡面會去收集node ready的狀态, node上剩餘的Allocatable，就是CPU記憶體的剩餘資訊。其實有了這些資訊之後，我們再做自定義排程，完全是規劃中的一個事情。
整體的排程設計完之後，我們希望在工行産生的效果如下圖，當我排程 deployment A時，它是因為偏好的設定排程到cluster 1; deployment B因為一個故障域打散，它可能排程到了cluster 123三個叢集;deployment C也是一個故障域打散，但是因為資源餘量的原因，它多餘的pod被排程到了cluster 2這樣一個叢集。
跨叢集伸縮現在也是在Karmada規劃當中,現在我們可能還是需要解決一些問題:
1）考慮它跨叢集伸縮和子叢集伸縮之間的關系，因為現在往往我們上層業務應用配置的是單個叢集伸縮的政策，那麼整體跨叢集的政策與子叢集伸縮政策都配置時，它們之間的關系，到底是上層整體去做管理，還是有優先級，這可能是我們後面需要考慮的。
2）跨叢集伸縮和跨叢集排程間的關系，我覺得整體上還是以一個排程器為準。我的一個Multi-cluster僅僅負責伸縮的部分，比如到達了多少CPU、多少的記憶體，比如說70% -80%的時候去進行伸縮，伸縮到多少個，具體的排程還是由整體scheduler去進行。
3）需要彙聚各個叢集的metric，包括可能有一些性能瓶頸，它整體的工作模式，是需要我們後續去考慮的。
1）子叢集健康狀态的判斷政策：可能隻是與管理叢集失聯，子叢集本身業務容器均無損
2）自定義的故障恢複政策：Like RestartPolicy，Always、Never、OnFailure
3）重新排程和跨叢集伸縮的關系：希望它多叢集的排程是整體的一個排程器，而伸縮控制好它自己伸縮的一個政策即可。
整體對我們工行的一些業務場景而言，Karmada現在的能力及以後的規劃，可預見應該都是能解決我們業務場景痛點的。很高興有機會能夠加入到Karmada項目，希望有更多的開發者能夠加入Karmada，與我們共建社群，共建這樣一個多雲管理的新項目。
附：Karmada社群技術交流位址
項目位址：https://github.com/karmada-io/karmada
Slack位址：https://karmada-io.slack.com
點選關注，第一時間了解華為雲新鮮技術~