智領(lǐng)云聯(lián)合創(chuàng)始人 & CEO彭鋒博士曾以Twitter公司為例，強(qiáng)調(diào)云原生架構(gòu)的優(yōu)勢(shì)。

“Twitter從2011年開(kāi)始建設(shè)自己內(nèi)部的私有云平臺(tái)，我們看到的是業(yè)務(wù)開(kāi)發(fā)效率數(shù)量級(jí)的增長(zhǎng)，同時(shí)避免了部門(mén)墻，避免了數(shù)據(jù)孤島和應(yīng)用孤島（因?yàn)槎急仨氉袷卦破脚_(tái)和其上的大數(shù)據(jù)平臺(tái)的發(fā)布規(guī)范）。從80臺(tái)機(jī)器的Hadoop集群，到8000臺(tái)機(jī)器的全局?jǐn)?shù)據(jù)平臺(tái)，在統(tǒng)一集群中不斷擴(kuò)展數(shù)據(jù)能力矩陣，支撐業(yè)務(wù)運(yùn)營(yíng)。很多數(shù)據(jù)能力建設(shè)的工作，也因?yàn)閼?yīng)用的云原生化成為可能?！?/p>

對(duì)比企業(yè)在使用傳統(tǒng)大數(shù)據(jù)平臺(tái)時(shí)遇到的困難和難點(diǎn)，云原生架構(gòu)的優(yōu)勢(shì)便能夠更好地凸顯出來(lái)。那么，云原生架構(gòu)又是如何解決這些難點(diǎn)，成為如今大數(shù)據(jù)平臺(tái)搭建的市場(chǎng)趨勢(shì)呢？

傳統(tǒng)大數(shù)據(jù)平臺(tái)的難點(diǎn)，主要體現(xiàn)在其組件安裝運(yùn)維復(fù)雜：

  1. 每個(gè)大數(shù)據(jù)組件都有自己的安裝流程，系統(tǒng)要求，第三方庫(kù)支持要求
  2. 獨(dú)立的分布式管理，高可用，容錯(cuò)，日志，授權(quán)，鑒權(quán)機(jī)制
  3. 難以實(shí)現(xiàn)對(duì)于多租戶，資源隔離，審計(jì)，計(jì)費(fèi)的支持
  4. 工具體系復(fù)雜，無(wú)法支持CI/CD，系統(tǒng)測(cè)試，質(zhì)量控制
  5. 無(wú)法實(shí)現(xiàn)大數(shù)據(jù)組件及應(yīng)用的混合調(diào)度，資源使用率低

因此，數(shù)據(jù)應(yīng)用的開(kāi)發(fā)流程及管理散布在各個(gè)系統(tǒng)組件中，缺乏統(tǒng)一全局的管理，開(kāi)發(fā)運(yùn)營(yíng)效率低。

傳統(tǒng)大數(shù)據(jù)平臺(tái)存在的問(wèn)題，已經(jīng)逐漸無(wú)法支撐數(shù)據(jù)驅(qū)動(dòng)業(yè)務(wù)運(yùn)營(yíng)更為豐富的需求，所以呈現(xiàn)出來(lái)的市場(chǎng)趨勢(shì)就是大數(shù)據(jù)平臺(tái)的云原生化。具體來(lái)看：

規(guī)劃設(shè)計(jì)

接下來(lái)，我們要討論的是怎樣規(guī)劃設(shè)計(jì)這樣的云平臺(tái)系統(tǒng)，這部分可以從基礎(chǔ)設(shè)施層（IaaS）、平臺(tái)服務(wù)層(PaaS)，以及應(yīng)用交付層來(lái)看，而每個(gè)層面都需要結(jié)合當(dāng)前的業(yè)務(wù)規(guī)模和需求來(lái)權(quán)衡一些問(wèn)題，比如

我們的目標(biāo)是要去交付一個(gè)K8s云平臺(tái)，需求可以先拆分為以下三大方面：

首先 IaaS 層的建設(shè)，我們要決定是托管在公有云，還是自建私有云，或者是最復(fù)雜的混合云架構(gòu)；

其次 PaaS 層的建設(shè)，我們要決定是用原生的K8s，還是發(fā)型版的K8s（各公有云廠商的K8s服務(wù)，或者像Kubesphere、Rancher、OpenShift這些面向私有發(fā)布的發(fā)行版等）；

最后是應(yīng)用交付的體系，我們的目的不是為了搭建K8s而搭建，交付了K8s平臺(tái)之后，更重要的是如何快速、靈活地將業(yè)務(wù)系統(tǒng)“搬”到K8s平臺(tái)上來(lái)，并在未來(lái)能夠充分利用好K8s容器編排的各種特性，例如容器運(yùn)行時(shí)/網(wǎng)絡(luò)/存儲(chǔ)接口、故障自動(dòng)遷移、彈性伸縮、租戶控制等。

針對(duì)以上三個(gè)方面的設(shè)計(jì)規(guī)劃，其現(xiàn)狀及問(wèn)題包括：

IaaS層：最主要的是管理成本的權(quán)衡：公有云搭建最快，具備公有云產(chǎn)品使用的能力即可，管理成本相對(duì)較低，但產(chǎn)品價(jià)格很貴；私有云需要有虛擬化平臺(tái)建設(shè)及運(yùn)維的能力，管理成本相對(duì)較高；混合云前兩者的能力都需要，還需要具備網(wǎng)絡(luò)基礎(chǔ)設(shè)施建設(shè)的能力，管理成本最高。

PaaS層：官方開(kāi)源版本無(wú)任何定制，但要構(gòu)建一套完整的生態(tài)系統(tǒng)，需要自行搭建例如倉(cāng)庫(kù)、監(jiān)控、報(bào)警、日志、負(fù)載均衡等額外的系統(tǒng)，技術(shù)選型可控但對(duì)團(tuán)隊(duì)能力要求高；發(fā)行版一般提供一套比較完備的生態(tài)系統(tǒng)，但技術(shù)選型往往不可控，容易被綁定，另外難以滿足自定義需求的時(shí)候，還是需要自行建設(shè)；除此之外，K8s的版本發(fā)布非?？?，如果想用新的特性或者修復(fù)bug，需要跟上新版本，但底層平臺(tái)升級(jí)往往是非常吃力且容易出事故的。

應(yīng)用交付：K8s的優(yōu)勢(shì)是容器化編排能力很強(qiáng)，一開(kāi)始看上去像海面上一座優(yōu)美的小島；劣勢(shì)是它的系統(tǒng)架構(gòu)、概念原理、管理使用非常復(fù)雜，等深入了解了之后才發(fā)現(xiàn)小島原來(lái)只是露出海面的冰山一角；對(duì)于應(yīng)用開(kāi)發(fā)者來(lái)說(shuō)，平臺(tái)工程師應(yīng)該把容器編排層的能力抽象隔離并封裝簡(jiǎn)化，讓上層用戶專(zhuān)注于應(yīng)用開(kāi)發(fā)，不需要承受整個(gè)冰山的重量。

實(shí)現(xiàn)路徑

結(jié)合規(guī)劃設(shè)計(jì)各層面的具體實(shí)踐，接下來(lái)要講一講我們自己的實(shí)現(xiàn)路徑。首先，在基礎(chǔ)設(shè)施層和平臺(tái)服務(wù)層，面向公有云場(chǎng)景，我們的實(shí)踐是基于阿里云容器服務(wù)ACK去構(gòu)建在公有云場(chǎng)景的K8s平臺(tái)。

ACK 整合了阿里云虛擬化、存儲(chǔ)、網(wǎng)絡(luò)和安全能力，提供高性能可伸縮的容器應(yīng)用管理能力，支持企業(yè)級(jí)容器化應(yīng)用的全生命周期管理。

ACK當(dāng)前支持的版本為：1.22.3 和 1.20.11，僅發(fā)布Kubernetes雙數(shù)號(hào)的大版本，版本支持策略如下：

集群創(chuàng)建：ACK支持Kubernetes兩個(gè)大版本的創(chuàng)建，例如v1.16、v1.18。當(dāng)新版本Kubernetes發(fā)布時(shí)，較老的一個(gè)版本將不再開(kāi)放創(chuàng)建功能。

升級(jí)和運(yùn)維保障：ACK保障最近的三個(gè)Kubernetes大版本的穩(wěn)定運(yùn)行，同時(shí)支持最新版本往前兩個(gè)大版本的升級(jí)功能，例如當(dāng)前最新版本為v1.20，則ACK支持v1.18、v1.16的升級(jí)功能。

工單答疑：ACK僅提供最近的三個(gè)Kubernetes大版本的技術(shù)支持。

那么，在私有云場(chǎng)景中，我們的建設(shè)實(shí)踐是采用了VMware的一套技術(shù)架構(gòu)，物理機(jī)采用DELL的PowerEdge系列。并在物理機(jī)上部署VMware ESXi，通過(guò)VMware vCenter Server將多臺(tái)物理機(jī)資源組成資源池，組成虛擬化管理平臺(tái)。

除此之外，在私有發(fā)布場(chǎng)景中，還需要去部署K8s的整個(gè)系統(tǒng)，我們選用了青云的KubeKey。

這款開(kāi)源K8s安裝器項(xiàng)目，可以輕松、高效、靈活地單獨(dú)或整體安裝 Kubernetes 和 KubeSphere。

支持的Linux 發(fā)行版本

支持的Kubernetes 版本

使用起來(lái)也比較簡(jiǎn)單，具體操作如下：

./kk create cluster -f config.yaml

./kk add nodes -f config.yaml

./kk delete node <nodeName> -f config.yaml

./kk create cluster -f config.yaml

在應(yīng)用交付層，我們的實(shí)踐是基于KubeVela這一引擎來(lái)做平臺(tái)建設(shè)。

KubeVela 作為一個(gè)開(kāi)箱即用的現(xiàn)代化應(yīng)用交付與管理平臺(tái)，使得應(yīng)用在面向混合云環(huán)境中的交付更簡(jiǎn)單、快捷。使用 KubeVela 的軟件開(kāi)發(fā)團(tuán)隊(duì)，可以按需使用云原生能力構(gòu)建應(yīng)用，隨著團(tuán)隊(duì)規(guī)模的發(fā)展、業(yè)務(wù)場(chǎng)景的變化擴(kuò)展其功能，一次構(gòu)建，隨處運(yùn)行。

KubeVela 圍繞著云原生應(yīng)用交付和管理場(chǎng)景展開(kāi)，背后的應(yīng)用交付模型是 Open Application Model，簡(jiǎn)稱(chēng) OAM ，其核心是將應(yīng)用部署所需的所有組件和各項(xiàng)運(yùn)維動(dòng)作，描述為一個(gè)統(tǒng)一的、與基礎(chǔ)設(shè)施無(wú)關(guān)的“部署計(jì)劃”，進(jìn)而實(shí)現(xiàn)在混合環(huán)境中標(biāo)準(zhǔn)化和高效率的應(yīng)用交付。

為什么要用 KubeVela？

云原生技術(shù)的發(fā)展趨勢(shì)正在朝著利用 Kubernetes 作為公共抽象層來(lái)實(shí)現(xiàn)高度一致的、跨云、跨環(huán)境的的應(yīng)用交付而不斷邁進(jìn)。然而，盡管 Kubernetes 在統(tǒng)一底層基礎(chǔ)架構(gòu)細(xì)節(jié)方面表現(xiàn)出色，它并沒(méi)有在混合的分布式部署環(huán)境之上提供應(yīng)用層的軟件交付模型和抽象。我們已經(jīng)看到，這種缺乏統(tǒng)一上層抽象的軟件交付過(guò)程，不僅降低了生產(chǎn)力、影響了用戶體驗(yàn)，甚至還會(huì)導(dǎo)致生產(chǎn)中出現(xiàn)錯(cuò)誤和故障。

然而，為現(xiàn)代微服務(wù)應(yīng)用的交付過(guò)程建模是一個(gè)高度碎片化且充滿挑戰(zhàn)的事情。到目前為止，絕大多數(shù)試圖解決上述問(wèn)題的技術(shù)方案，要么過(guò)于簡(jiǎn)單以致于無(wú)法覆蓋實(shí)際生產(chǎn)使用中的問(wèn)題，要么過(guò)于復(fù)雜難以落地使用。云原生帶來(lái)的基礎(chǔ)設(shè)施能力爆發(fā)式增長(zhǎng)也決定了新一代的應(yīng)用管理平臺(tái)不能以硬編碼的方式做能力的集成和 UI 的構(gòu)建，除了滿足基礎(chǔ)的功能和場(chǎng)景，平臺(tái)本身的擴(kuò)展能力成為了新時(shí)代應(yīng)用管理平臺(tái)的核心訴求。這就意味著平臺(tái)不僅要簡(jiǎn)單易用，還要能夠隨著應(yīng)用交付和管理的需求復(fù)雜度提升能夠不斷擴(kuò)張，能夠讓開(kāi)發(fā)者自助式的接入和使用，充分享受云原生生態(tài)的紅利。

這也是 KubeVela 出現(xiàn)的核心價(jià)值：它既能夠簡(jiǎn)化面向混合環(huán)境（多集群/多云/混合云/分布式云）的應(yīng)用交付過(guò)程；同時(shí)又足夠靈活可以隨時(shí)滿足業(yè)務(wù)不斷高速變化所帶來(lái)的迭代壓力。它本身是一個(gè)面向混合交付環(huán)境同時(shí)又高可擴(kuò)展的應(yīng)用交付引擎，滿足平臺(tái)構(gòu)建者的擴(kuò)展和自建需求；同時(shí)又附加了一系列開(kāi)箱即用的擴(kuò)展組件，能夠讓開(kāi)發(fā)者自助式的開(kāi)發(fā)、交付云原生應(yīng)用。

KubeVela 核心功能

統(tǒng)一的應(yīng)用交付模型：KubeVela 創(chuàng)新性的提出了 開(kāi)放應(yīng)用模型（OAM）來(lái)作為應(yīng)用交付的頂層抽象，該模型支持交付任意類(lèi)型的工作負(fù)載包括容器、數(shù)據(jù)庫(kù)甚至是虛擬機(jī)到不同的云和 Kubernetes 集群中。用戶無(wú)需關(guān)心任何基礎(chǔ)設(shè)施細(xì)節(jié)，只需要專(zhuān)注于定義和部署應(yīng)用即可。應(yīng)用只需要一次編排，就可以隨處運(yùn)行，免去了適配不同平臺(tái)的痛苦。

聲明式交付工作流：KubeVela 的整個(gè)交付模型完全是由用戶聲明式驅(qū)動(dòng)的，兼顧用戶體驗(yàn)和健壯性，其控制循環(huán)能夠有效避免配置漂移，且具備多租權(quán)限控制能力。用戶可以通過(guò) CUE 語(yǔ)言（一種源自 Google Borg 系統(tǒng)的數(shù)據(jù)配置語(yǔ)言）自由的根據(jù)需求場(chǎng)景來(lái)設(shè)計(jì)和選用交付工作流中的每一個(gè)步驟，滿足業(yè)務(wù)快速增長(zhǎng)的需求，同時(shí)持續(xù)保證生產(chǎn)環(huán)境面向終態(tài)的穩(wěn)定性。

多集群/混合云應(yīng)用交付控制平面：KubeVela 原生支持豐富的多集群/混合環(huán)境持續(xù)交付策略，也支持跨環(huán)境交付。這些交付策略為你的分布式交付流程提供了充足的效率和安全的保證。KubeVela 提供的中心化管控能力也減輕了到每一個(gè)集群去排查問(wèn)題的負(fù)擔(dān)，針對(duì)不同的平臺(tái)提供統(tǒng)一的體驗(yàn)，為了享受自動(dòng)化交付的便利，你再也不需要成為 Kubernetes 專(zhuān)家。

KubeVela vs. 傳統(tǒng) PaaS 平臺(tái)

傳統(tǒng) PaaS (如 Heroku，Cloud Foundry 等) 提供完整的應(yīng)用程序部署和管理功能，旨在提高開(kāi)發(fā)人員的體驗(yàn)和效率。在這個(gè)場(chǎng)景下，KubeVela 也有著相同的目標(biāo)。

不過(guò)，KubeVela 和它們最大的區(qū)別在于其可擴(kuò)展性。

KubeVela 是可編程的。它的交付工作流乃至整個(gè)應(yīng)用交付與管理能力集都是由獨(dú)立的可插拔模塊構(gòu)成的，這些模塊可以隨時(shí)通過(guò)編寫(xiě) CUE 模板的方式進(jìn)行增/刪/重定義且變更會(huì)即時(shí)生效。與這種機(jī)制相比，傳統(tǒng)的 PaaS 系統(tǒng)的限制非常多：它們需要對(duì)應(yīng)用類(lèi)型和提供的能力進(jìn)行各種約束來(lái)實(shí)現(xiàn)更好的用戶體驗(yàn)，但隨著應(yīng)用交付需求的增長(zhǎng)，用戶的訴求就一定會(huì)超出 PaaS 系統(tǒng)的能力邊界。這種情況在 KubeVela 平臺(tái)中則永遠(yuǎn)不會(huì)發(fā)生。

此外，KubeVela 是一個(gè)獨(dú)立于運(yùn)行時(shí)集群的應(yīng)用交付控制平面（這是我們認(rèn)為的下一代 PaaS 系統(tǒng)的合理形態(tài)），而現(xiàn)有的 PaaS 則往往選擇以插件形式部署在運(yùn)行時(shí)集群當(dāng)中。

下面，我們來(lái)舉一個(gè)最簡(jiǎn)單的示例來(lái)看一看怎樣將一個(gè)應(yīng)用或服務(wù)，能夠快速的在K8s上以容器化的方式運(yùn)行起來(lái)：

交付Helm組件

在交付應(yīng)用后，我們需要運(yùn)維該應(yīng)用來(lái)觀測(cè)它的指標(biāo)和日志。

基于此，我們?cè)贙ubeVela引擎構(gòu)建云平臺(tái)時(shí)，在日志、監(jiān)控告警等層面做了相應(yīng)的自動(dòng)化的集成。主要的四個(gè)方面包括監(jiān)控目標(biāo)、監(jiān)控面板、日志采集、告警規(guī)則特征上做了相應(yīng)的開(kāi)發(fā)。

下圖為監(jiān)控目標(biāo)特征、監(jiān)控面板特征、日志采集特征、告警規(guī)則特征：

向上賦能

基于前面構(gòu)建好的底層云平臺(tái)系統(tǒng)，最后我們講講它的能力。

由于我們公司核心產(chǎn)品是一個(gè)一站式的云原生DataOps平臺(tái)，底層的云平臺(tái)系統(tǒng)搭載了上層的容器化大數(shù)據(jù)平臺(tái)、數(shù)據(jù)集成開(kāi)發(fā)平臺(tái)、數(shù)據(jù)資產(chǎn)運(yùn)營(yíng)平臺(tái)、數(shù)據(jù)質(zhì)量平臺(tái)等各種數(shù)據(jù)平臺(tái)系統(tǒng)。

由于核心引擎提供的靈活、可擴(kuò)展性，未來(lái)我們的云平臺(tái)還能夠?qū)⒏嗟腒8s生態(tài)及系統(tǒng)能力納入進(jìn)來(lái)，向上面的業(yè)務(wù)層提供更強(qiáng)大的功能及性能支撐。

具體來(lái)說(shuō)，目前的階段性成果體現(xiàn)在：

大數(shù)據(jù)組件的快速交付：Hive、Spark、HDFS、Kafka、Flink…

數(shù)據(jù)應(yīng)用的快速開(kāi)發(fā)集成：自定義程序發(fā)布

統(tǒng)一的可觀測(cè)性集成和展示：監(jiān)控、告警、日志

全系統(tǒng)的多租戶實(shí)現(xiàn)：租戶配額管理、服務(wù)/數(shù)據(jù)的鑒權(quán)+授權(quán)

未來(lái)更進(jìn)一步向上賦能DataOps的能力則體現(xiàn)在：

開(kāi)發(fā)運(yùn)維：CI/CD，多環(huán)境管理

可觀測(cè)性：大數(shù)據(jù)平臺(tái)全鏈路追蹤

彈性伸縮：大數(shù)據(jù)作業(yè)資源彈性、自適應(yīng)

增強(qiáng)型調(diào)度：Volcano Scheduler，提供更適合大數(shù)據(jù)系統(tǒng)的使用

分享到

zhupb

相關(guān)推薦