文章目錄

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

---

前言

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

---

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

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

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

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

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

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

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

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

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

1.3、工行金融云成效

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

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

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

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

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

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

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

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

k8s 集群總數(shù)近百個(gè)，并且在不斷地?cái)U(kuò)張中，細(xì)究主要原因我們將其分為以下四點(diǎn)。

1.5.1、集群種類多

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

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

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

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

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

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

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

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

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

1.7、解決方案下存在的問(wèn)題

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

二、架構(gòu)選型

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

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

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

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

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

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

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

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

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

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

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

2.5、Karmada 現(xiàn)真身

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

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

三、為什么選擇 Karmada？

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

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

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

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

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

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

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

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

3.4、Propagation 機(jī)制

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

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

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

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

• 支持 cluster\namespace scope。

3.5、Work 機(jī)制

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

Work 信息配置如下圖所示：

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

3.6、Karmada 優(yōu)勢(shì)

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

3.6.1、資源調(diào)度

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

3.6.2、容災(zāi)

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

3.6.3、集群管理

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

3.6.4、資源管理

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

四、落地展望

4.1、云平臺(tái)集成

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

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

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

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

4.3、跨集群伸縮

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

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

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

---

總結(jié)

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

---

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

總結(jié)

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

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