摘要：在華爲開發者大會（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）爲什麼不把調度以及故障恢復的能力全部集成到剛剛的雲管平臺。這部分是我們希望整體的多集羣管理模塊，從雲管平臺中隔離出來，下沉到下面的一個多集羣管理模塊。
基於以上這些目標，我們進行社區解決方案的一些調研。
Kubefed
我們調研的第一個是之前比較火的一個集羣聯邦federation項目， federation整體是分v1和v2的版本，我們去調研的時候，那個時候已經主要是v2也就是Kubefed。
Kubefed本身也能解決一部分問題，它具有集羣生命週期管理、Override以及基礎調度的能力，但對我們來說它有幾點致命的硬傷，目前還無法滿足我們的需求：
1）調度層面是非常基礎的一個調度能力，他們也不準備在調度方面花費更大的精力支持自定義調度，不支持按資源餘量調度。
2）第二點也是比較爲人所詬病的，它本身不支持原生k8s對象，我要在它的管理集羣中使用它新定義的CRD，對於我們已經使用了這麼久的k8s原生資源對象的上層應用，雲管平臺本身對接API方面，我們也需要重新進行開發，這部分成本是非常大的。
3）它基本不具備故障自動遷移能力
RHACM
我們調研的第二個項目是RHACM，該項目主要由紅帽和 IBM主導，整體調研下來，發現它的功能是比較健全的，包括我們剛剛所提的能力也是具備的，而且它上層應用application層對於對用戶那一層的能力比較靠近雲管平臺這樣一個定位，但它僅僅支持Openshift，對於我們已經存量有這麼多的k8s集羣來說，改造成本非常大，而且太重了。而在我們進行研究的時候，它還沒有開源，社區的整體支持力度是不夠的。
Karmada
當時我們和華爲交流到了多集羣管理的一個現狀以及痛點，包括對社區聯邦類項目的討論，我們雙方也非常希望能夠在這方面革新，下圖爲Karmada的功能視圖：
Karmada功能視圖
從它整體功能視圖及規劃來看，和我們上文提到的目標非常契合，它有集羣整體的生命週期管理、集羣註冊、多集羣伸縮、多集羣調度、整體統一的API、底層標準API支持，它都是CNI/CSI在它整體功能視圖裏，包括上層的應用、對Istio、Mash、CI/CD等都有整體規劃上的考慮。因此基於整體思路，它的功能與我們非常契合，工行也決定投入到這個項目中來，跟華爲和我們很多的項目夥伴共建Karmada項目，並把它回饋到我們社區整體。
爲什麼選擇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機制
首先我們定義的是 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綁定即可。
Work機制
在我們已經建立了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優勢
工行在具體使用與驗證之後，發現Karmada有以下幾點優勢：
1）資源調度
- 自定義跨集羣調度策略
- 對上層應用透明
- 支持兩種資源綁定調度
2）容災
- 動態binding調整
- 按照集羣標籤或故障域自動分發資源對象
3）集羣管理
- 支持集羣註冊
- 全生命週期管理
- 統一標準的API
4）資源管理
- 支持k8s原生對象
- works支持子集羣資源部署狀態獲取
- 資源對象分發既支持pull也支持push方式
Karmada在工行的落地情況及對未來展望
首先我們看下Karmada其中的兩個功能怎麼去納管集羣和資源下發？
目前爲止工行的測試環境中Karmada已經對存量集羣進行了一些納管，在對未來規劃方面，一個比較關鍵的點是如何跟我們整體雲平臺進行集成。
雲平臺集成
在這方面我們希望之前提到的多集羣管理、跨集羣調度、跨集羣伸縮、故障恢復以及資源整體視圖方面都全部下沉到Karmada這樣一個控制平面。
對於上層的雲管平臺，我們更注重它對用戶業務的管理，包括用戶管理、應用管理、進項管理等，也包括由Karmada衍生出來的比如說Policy定義在雲平臺上。上圖比較簡略，具體的雲平臺可能還要連一根線到每一個k8s集羣，比如pod在哪個node上，Karmada的平面可能是不關心的，但具體要知道pod位置類的信息，可能還要從k8s的子集羣獲取，這個也可能是我們後面集成中需要去解決的問題，當然這也是符合Karmada本身的設計理念，它是不需要關心具體的pod在k8s子集羣的哪個位置。
未來展望1-跨集羣調度
對於跨集羣調度方面，Karmada已經支持了上文提到的故障域打算、應用偏好、權重對比。但是我們希望它也能夠根據集羣的資源與量去進行調度，這樣不會產生各個子集羣當中資源不均衡的狀態。雖然它暫時是沒有實現的，但它的一個CRD叫cluster， cluster有一個狀態信息，這個狀態信息裏面會去收集node ready的狀態, node上剩餘的Allocatable，就是CPU內存的剩餘信息。其實有了這些信息之後，我們再做自定義調度，完全是規劃中的一個事情。
整體的調度設計完之後，我們希望在工行產生的效果如下圖，當我調度 deployment A時，它是因爲偏好的設置調度到cluster 1; deployment B因爲一個故障域打散，它可能調度到了cluster 123三個集羣;deployment C也是一個故障域打散，但是因爲資源餘量的原因，它多餘的pod被調度到了cluster 2這樣一個集羣。
未來展望2-跨集羣伸縮
跨集羣伸縮現在也是在Karmada規劃當中,現在我們可能還是需要解決一些問題:
1）考慮它跨集羣伸縮和子集羣伸縮之間的關係，因爲現在往往我們上層業務應用配置的是單個集羣伸縮的策略，那麼整體跨集羣的策略與子集羣伸縮策略都配置時，它們之間的關係，到底是上層整體去做管理，還是有優先級，這可能是我們後面需要考慮的。
2）跨集羣伸縮和跨集羣調度間的關係，我覺得整體上還是以一個調度器爲準。我的一個Multi-cluster僅僅負責伸縮的部分，比如到達了多少CPU、多少的內存，比如說70% -80%的時候去進行伸縮，伸縮到多少個，具體的調度還是由整體scheduler去進行。
3）需要匯聚各個集羣的metric，包括可能有一些性能瓶頸，它整體的工作模式，是需要我們後續去考慮的。
未來展望3-跨集羣故障恢復及高可用
1）子集羣健康狀態的判斷策略：可能只是與管理集羣失聯，子集羣本身業務容器均無損
2）自定義的故障恢復策略：Like RestartPolicy，Always、Never、OnFailure
3）重新調度和跨集羣伸縮的關係：希望它多集羣的調度是整體的一個調度器，而伸縮控制好它自己伸縮的一個策略即可。
整體對我們工行的一些業務場景而言，Karmada現在的能力及以後的規劃，可預見應該都是能解決我們業務場景痛點的。很高興有機會能夠加入到Karmada項目，希望有更多的開發者能夠加入Karmada，與我們共建社區，共建這樣一個多雲管理的新項目。
附：Karmada社區技術交流地址
項目地址：https://github.com/karmada-io/karmada
Slack地址：https://karmada-io.slack.com