文章目錄

• 前言
• 一、工行業(yè)務(wù)背景
• • 1.1、工行云計算架構(gòu)組成
  • 1.2、工行云平臺技術(shù)棧
  • 1.3、工行金融云成效
  • • 1.3.1、入云規(guī)模同業(yè)最大
    • 1.3.2、業(yè)務(wù)如云場景廣
  • 1.4、容災(zāi)及高可用保障
  • 1.5、PaaS 層多集群現(xiàn)狀
  • • 1.5.1、集群種類多
    • 1.5.2、k8s 集群 node 數(shù)量限制
    • 1.5.3、業(yè)務(wù)擴展快
    • 1.5.4、故障域分區(qū)多
  • 1.6、針對多集群現(xiàn)狀的解決方案
  • 1.7、解決方案下存在的問題
• 二、架構(gòu)選型
• • 2.1、實現(xiàn)目標(biāo)
  • 2.2、為什么希望部分模塊是具有社區(qū)支持度的開源項目？
  • 2.3、Kubefed 的優(yōu)勢與不足
  • 2.4、RHACM 的優(yōu)勢與不足
  • 2.5、Karmada 現(xiàn)真身
• 三、為什么選擇 Karmada？
• • 3.1、技術(shù)架構(gòu).
  • 3.2、技術(shù)優(yōu)勢
  • 3.3、Karmada Resources 如何分發(fā)？
  • 3.4、Propagation 機制
  • 3.5、Work 機制
  • 3.6、Karmada 優(yōu)勢
  • • 3.6.1、資源調(diào)度
    • 3.6.2、容災(zāi)
    • 3.6.3、集群管理
    • 3.6.4、資源管理
• 四、落地展望
• • 4.1、云平臺集成
  • 4.2、跨集群調(diào)度
  • 4.3、跨集群伸縮
  • 4.4、跨集群故障恢復(fù)與高可用
• 總結(jié)

---

前言

華為云 AI 主打智慧園區(qū)、智慧物流兩個行業(yè)數(shù)字化轉(zhuǎn)型的解決方案。AI 開發(fā)的難點較多，在未接觸 ModelArts 之前，首先在數(shù)據(jù)的預(yù)處理方面，標(biāo)注會花費大量的時間；在訓(xùn)練的時候需要購置很多的 GPU 的一些設(shè)備，這是價值不菲的；在部署方面非常的困難、繁瑣。近年來隨著云原生技術(shù)的不斷成熟，越來越多的企業(yè)選擇云原生作為數(shù)字化轉(zhuǎn)型的核心支撐，華為云率先提出云原生 2.0 的理念，將引領(lǐng)企業(yè)云化建設(shè)從“On Cloud”邁向“In Cloud”，進入智能升級新階段。

---

一、工行業(yè)務(wù)背景

近幾年互聯(lián)網(wǎng)的崛起對金融領(lǐng)域的金融模式、服務(wù)模式產(chǎn)生了巨大的沖擊，迫使行業(yè)不得不做出巨大的革新。銀行業(yè)務(wù)系統(tǒng)“入云”已經(jīng)是大勢所趨，在這方面工商銀行已經(jīng)處于行業(yè)一線，截止目前已經(jīng)形成了基礎(chǔ)設(shè)施云（Iaas）、應(yīng)用平臺云（Paas）、金融生態(tài)云（SaaS）以及具有工行特色的分行云（BCloud）四位一體的云平臺架構(gòu)。

1.1、工行云計算架構(gòu)組成

工行云平臺具體架構(gòu)如下圖所示：

以上四大模塊各自分發(fā)所負責(zé)的內(nèi)容如下：

• 基礎(chǔ)設(shè)施云（IaaS）：面向基礎(chǔ)設(shè)施運維人員，提供計算、存儲、網(wǎng)絡(luò)等底層資源快速供給的能力。
• 應(yīng)用平臺云（PaaS）：面向應(yīng)用運維人員，提供軟件資源（環(huán)境、中間件和應(yīng)用程序）快速供給及快速部署的能力。
• 金融生態(tài)云（SaaS）：面向企業(yè)客戶，聯(lián)合合作伙伴，提供與工行金融服務(wù)緊密集成的行業(yè)解決方案，同時為合作伙伴提供 SaaS 軟件托管及運營管理服務(wù)。
• 分行云（BCloud）：面向工行的“公有云”，提供分行應(yīng)用軟件托管、DevOps、運維管理能力并輸出總行新的一些云計算建設(shè)成果。

1.2、工行云平臺技術(shù)棧

工行云平臺基于業(yè)界領(lǐng)先云產(chǎn)品和開源主流技術(shù)，結(jié)合工行特色實現(xiàn)金融級自主定制，技術(shù)棧如下圖所示：

• 基于華為云 Stark 8.0 產(chǎn)品結(jié)合運營運維需求進行客戶化定制，構(gòu)建新一代基礎(chǔ)設(shè)施云。
• 通過引入開源容器技術(shù) Docker、容器集群調(diào)度技術(shù) Kubernetes 等，自主研發(fā)建設(shè)應(yīng)用平臺云。
• 基于 HaProxy、Dubbo、ElasticSerch 等建立負載均衡、微服務(wù)、全息監(jiān)控、日志中心等周邊配套云生態(tài)。

1.3、工行金融云成效

1.3.1、入云規(guī)模同業(yè)最大

應(yīng)用平臺云容器規(guī)模超 20w，業(yè)務(wù)容器規(guī)模 55000+，核心應(yīng)用基本全面入容器云，入云情況如下圖所示：

1.3.2、業(yè)務(wù)如云場景廣

應(yīng)用入云涉及業(yè)務(wù)廣，并支撐多個關(guān)鍵領(lǐng)域，如以個人金融、線上渠道為代表的核心業(yè)務(wù)應(yīng)用；以分布式服務(wù)框架、MySQL 數(shù)據(jù)庫為代表的技術(shù)支撐應(yīng)用；以物聯(lián)網(wǎng)、區(qū)塊鏈、機器學(xué)習(xí)、大數(shù)據(jù)為代表的新技術(shù)領(lǐng)域應(yīng)用，綜合情況如下圖所示：

1.4、容災(zāi)及高可用保障

• 云平臺支持多層次故障保護機制，確保同一業(yè)務(wù)的不同實例會均衡分發(fā)到兩地三中心的不同資源域，在低粒度下細分故障域，確保單個存儲、單個集群甚至單個數(shù)據(jù)中心發(fā)生故障時，不會影響業(yè)務(wù)的整體可用性，調(diào)度情況如下圖所示：

• 在故障情況下，基于 k8s 自身優(yōu)勢，云平臺通過容器重啟及自動漂移，實現(xiàn)故障的自動恢復(fù)，如下圖所示：

1.5、PaaS 層多集群現(xiàn)狀

k8s 集群總數(shù)近百個，并且在不斷地擴張中，細究主要原因我們將其分為以下四點。

1.5.1、集群種類多

由于業(yè)務(wù)場景較為廣泛，支持 GPU 的設(shè)備、中間件、數(shù)據(jù)庫、底層的容器網(wǎng)絡(luò)，不同的需求導(dǎo)致產(chǎn)生不同的解決方案，所以需要為不同的業(yè)務(wù)場景定制不同的集群，如下圖所示：

1.5.2、k8s 集群 node 數(shù)量限制

受到 k8s 本身性能的限制，每個集群都有自己數(shù)量的上限。

1.5.3、業(yè)務(wù)擴展快

截至目前，包括傳統(tǒng)應(yīng)用在內(nèi)的各個業(yè)務(wù)在源源不斷地切入到容器云內(nèi)。

1.5.4、故障域分區(qū)多

以上述 1.4 內(nèi)容為例，兩地三中心的設(shè)計，包括三個 DC，每個 DC 內(nèi)部又通過不同的網(wǎng)絡(luò)區(qū)域防火墻進行隔離，以實現(xiàn)故障域分發(fā)，如下圖所示：

1.6、針對多集群現(xiàn)狀的解決方案

• 容器云云管平臺超級管理員接納、運維多集群。
• 上層業(yè)務(wù)應(yīng)用自主選擇集群，包括網(wǎng)絡(luò)區(qū)域在內(nèi)的等等內(nèi)容。
• 集群內(nèi)同一模版故障域自動打散。

1.7、解決方案下存在的問題

• 無跨集群自動伸縮。上了容器云之后，在業(yè)務(wù)峰值時集群內(nèi)部缺乏自動伸縮能力。
• 無跨集群調(diào)度能力。
• 集群對上層用戶不透明。
• 無跨集群故障自動遷移能力，整體上依靠“兩地三中心”架構(gòu)上的冗余，在自動化恢復(fù)上的高可用能力存在缺失。

二、架構(gòu)選型

2.1、實現(xiàn)目標(biāo)

基于以上存在的問題，我們定下了相應(yīng)的目標(biāo)，并對目前業(yè)界所采用的方案進行了技術(shù)選型，五個多云的集群模塊目標(biāo)如下表所示：

2.2、為什么希望部分模塊是具有社區(qū)支持度的開源項目？

• 希望整體的方案是在企業(yè)內(nèi)部自主可控的。
• 不希望花費更多的能力去重復(fù)“造輪子”。
• 希望整體管理的多集群模塊是從云管平臺中隔離出來，下沉到下面的多集群管理模塊之中。

基于以上的目標(biāo)，社區(qū)做了相當(dāng)多的調(diào)研，包括但不局限于社區(qū)中眾多的項目。

2.3、Kubefed 的優(yōu)勢與不足

優(yōu)勢：本身可以解決部分問題，具有集群生命周期管理，具有部分 Override，以及一些基礎(chǔ)調(diào)度的能力，其能力如下圖所示：

不足：調(diào)度層面太過于基礎(chǔ)，且 Kubefed 負責(zé)的社區(qū)團隊不準備在調(diào)度方面下更大的精力以支持如自定義的調(diào)度，包括不支持按資源余量的調(diào)度；最為人所詬病的一點——本身不支持原生 k8s 對象，需要在管理集群中使用其所新定義的一些 CRD，對于已經(jīng)使用了很久原生 k8s 資源對象的上層應(yīng)用，包括云管平臺在內(nèi)對接的一些 API 則需要進行重新開發(fā)，而這部分的成本是非常巨大的；整體上不具備故障自動遷移能力。基于以上不足，綜合考量，Kubefed 我們暫不考慮。

2.4、RHACM 的優(yōu)勢與不足

RHACM 是紅帽與 IBM 主導(dǎo)的項目，其功能架構(gòu)如下圖所示：

• 功能比較健全，但僅支持 Openshift，對于存量大量 k8s 集群的現(xiàn)狀而言，改造的成本是巨大的。
• 暫未開源，社區(qū)支持力度不夠。

2.5、Karmada 現(xiàn)真身

Karmada 整體的功能視圖如下圖所示：

Karmada 相當(dāng)契合我們在上述 2.1 小節(jié)中的實現(xiàn)目標(biāo)要求，具有整體的集群生命周期管理、集群注冊，包括多集群的伸縮、調(diào)度、統(tǒng)一的 API、底層的標(biāo)準 API 支持，并且 CNI、CSI 在其整體的功能視圖中，對 CI/CD 有整體上的規(guī)劃與考慮，所以工行最終決定投入到該項目中，與華為在內(nèi)的一系列伙伴共建該項目并回饋到社區(qū)中。

三、為什么選擇 Karmada？

3.1、技術(shù)架構(gòu).

Karmada 目前經(jīng)在社區(qū)中開源，相關(guān)信息及技術(shù)架構(gòu)大家可以移步社區(qū)查看，主要架構(gòu)如下圖所示：

3.2、技術(shù)優(yōu)勢

• Karmada 以類 k8s 的形式部署，以作為管理面集群，改造成本較低。
• Karmada-Controller-Manager 管理包括 cluster、policy、binding、works 等多種 CRD 資源作為管理端資源對象，沒有侵入到原生的 k8s 資源對象。
• Karmada 僅管理資源在集群間的調(diào)度，子集群內(nèi)分配高度自治，這對于分布式系統(tǒng)是必須的。

3.3、Karmada Resources 如何分發(fā)？

Karmada Resources 分發(fā)流程示意圖如下圖所示：

Karmada Resources 分發(fā)流程如下：

• 集群注冊到 Karmada。
• 定義 Resource Template。
• 制定分發(fā)策略 Propagation Policy。
• 制定 Override 策略。
• 看 Karmada 干活。

3.4、Propagation 機制

Propagation 機制分發(fā)如下：

Propagation Policy 信息配置如下圖所示：

• 集群親和性。
• 集群容忍。
• 按集群標(biāo)簽、故障域分發(fā)。

Resource Binding/Cluster Resource Binding 信息配置如下圖所示：

• 支持 cluster\namespace scope。

3.5、Work 機制

具體的 Work 分發(fā)機制如下圖所示：

Work 信息配置如下圖所示：

• Works 僅是 k8s Resource 的封裝。
• Works 的 status 作為子集群 resource 的反饋。

3.6、Karmada 優(yōu)勢

經(jīng)過驗證我們將 Karmada 的優(yōu)勢分為以下四塊。

3.6.1、資源調(diào)度

• 自定義跨集群調(diào)度策略。
• 對上層應(yīng)用透明。
• 支持兩種資源綁定調(diào)度。

3.6.2、容災(zāi)

• 動態(tài) binding 調(diào)整。
• 按照集群標(biāo)簽或故障域自動分發(fā)資源對象。

3.6.3、集群管理

• 支持集群注冊。
• 全生命周期管理。
• 統(tǒng)一標(biāo)準的 API。

3.6.4、資源管理

• 支持 k8s 原生對象。
• works 支持子集群資源部署狀態(tài)獲取。
• 資源對象分發(fā)既支持 pull 也支持 push 方式。

四、落地展望

4.1、云平臺集成

目前為止，在工行的測試環(huán)境中，Karmada 已經(jīng)對現(xiàn)存集群進行了納管，存在的問題是如何與整體云平臺進行集成。

4.2、跨集群調(diào)度

• 故障域打散。
• 應(yīng)用偏好設(shè)置、權(quán)重。
• 集群資源余量調(diào)度。

我們最終的期望實現(xiàn)效果如下圖所示：

4.3、跨集群伸縮

• 跨集群伸縮與子集群伸縮之間的關(guān)系。
• 跨集群伸縮與跨集群調(diào)度間的關(guān)系。

4.4、跨集群故障恢復(fù)與高可用

• 子集群健康狀態(tài)的判斷策略。可能只是與管理集群失聯(lián)，子集群本身業(yè)務(wù)容器均無損。
• 自定義的故障恢復(fù)策略。Like RestartPolicy、Always、Never、OnFailure。
• 重新調(diào)度和跨集群伸縮的關(guān)系。

---

總結(jié)

本文介紹了工行云平臺的現(xiàn)狀，包括容災(zāi)和多 k8s 集群，調(diào)研了業(yè)界多集群管理方案及選型，從而確定選擇 Karmada，介紹了包括其優(yōu)勢、技術(shù)架構(gòu)以及具體的機制，最后介紹了 Karmada 在工行的落地情況以及在未來中希望產(chǎn)生和應(yīng)用的場景。從 Karmada 近日宣布開源之后，我們希望有越來越多的開發(fā)者加入到社區(qū)中，共建多云管理的社區(qū)生態(tài)。

---

我是白鹿，一個不懈奮斗的程序猿。望本文能對你有所裨益，歡迎大家的一鍵三連！若有其他問題、建議或者補充可以留言在文章下方，感謝大家的支持！

總結(jié)

以上是生活随笔為你收集整理的Karmada 千级容器集群：工商银行业务容灾管理设计利器的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。