智領云聯(lián)合創(chuàng)始人 & CEO彭鋒博士曾以Twitter公司為例，強調(diào)云原生架構的優(yōu)勢。
“Twitter從2011年開始建設自己內(nèi)部的私有云平臺，我們看到的是業(yè)務開發(fā)效率數(shù)量級的增長，同時避免了部門墻，避免了數(shù)據(jù)孤島和應用孤島（因為都必須遵守云平臺和其上的大數(shù)據(jù)平臺的發(fā)布規(guī)范）。從80臺機器的Hadoop集群，到8000臺機器的全局數(shù)據(jù)平臺，在統(tǒng)一集群中不斷擴展數(shù)據(jù)能力矩陣，支撐業(yè)務運營。很多數(shù)據(jù)能力建設的工作，也因為應用的云原生化成為可能?！?/p>
對比企業(yè)在使用傳統(tǒng)大數(shù)據(jù)平臺時遇到的困難和難點，云原生架構的優(yōu)勢便能夠更好地凸顯出來。那么，云原生架構又是如何解決這些難點，成為如今大數(shù)據(jù)平臺搭建的市場趨勢呢？
傳統(tǒng)大數(shù)據(jù)平臺的難點，主要體現(xiàn)在其組件安裝運維復雜：
因此，數(shù)據(jù)應用的開發(fā)流程及管理散布在各個系統(tǒng)組件中，缺乏統(tǒng)一全局的管理，開發(fā)運營效率低。
傳統(tǒng)大數(shù)據(jù)平臺存在的問題，已經(jīng)逐漸無法支撐數(shù)據(jù)驅動業(yè)務運營更為豐富的需求，所以呈現(xiàn)出來的市場趨勢就是大數(shù)據(jù)平臺的云原生化。具體來看：
接下來，我們要討論的是怎樣規(guī)劃設計這樣的云平臺系統(tǒng)，這部分可以從基礎設施層（IaaS）、平臺服務層(PaaS)，以及應用交付層來看，而每個層面都需要結合當前的業(yè)務規(guī)模和需求來權衡一些問題，比如
我們的目標是要去交付一個K8s云平臺，需求可以先拆分為以下三大方面：
首先 IaaS 層的建設，我們要決定是托管在公有云，還是自建私有云，或者是最復雜的混合云架構；
其次 PaaS 層的建設，我們要決定是用原生的K8s，還是發(fā)型版的K8s（各公有云廠商的K8s服務，或者像Kubesphere、Rancher、OpenShift這些面向私有發(fā)布的發(fā)行版等）；
最后是應用交付的體系，我們的目的不是為了搭建K8s而搭建，交付了K8s平臺之后，更重要的是如何快速、靈活地將業(yè)務系統(tǒng)“搬”到K8s平臺上來，并在未來能夠充分利用好K8s容器編排的各種特性，例如容器運行時/網(wǎng)絡/存儲接口、故障自動遷移、彈性伸縮、租戶控制等。
針對以上三個方面的設計規(guī)劃，其現(xiàn)狀及問題包括：
IaaS層：最主要的是管理成本的權衡：公有云搭建最快，具備公有云產(chǎn)品使用的能力即可，管理成本相對較低，但產(chǎn)品價格很貴；私有云需要有虛擬化平臺建設及運維的能力，管理成本相對較高；混合云前兩者的能力都需要，還需要具備網(wǎng)絡基礎設施建設的能力，管理成本最高。
PaaS層：官方開源版本無任何定制，但要構建一套完整的生態(tài)系統(tǒng)，需要自行搭建例如倉庫、監(jiān)控、報警、日志、負載均衡等額外的系統(tǒng)，技術選型可控但對團隊能力要求高；發(fā)行版一般提供一套比較完備的生態(tài)系統(tǒng)，但技術選型往往不可控，容易被綁定，另外難以滿足自定義需求的時候，還是需要自行建設；除此之外，K8s的版本發(fā)布非?？?，如果想用新的特性或者修復bug，需要跟上新版本，但底層平臺升級往往是非常吃力且容易出事故的。
應用交付：K8s的優(yōu)勢是容器化編排能力很強，一開始看上去像海面上一座優(yōu)美的小島；劣勢是它的系統(tǒng)架構、概念原理、管理使用非常復雜，等深入了解了之后才發(fā)現(xiàn)小島原來只是露出海面的冰山一角；對于應用開發(fā)者來說，平臺工程師應該把容器編排層的能力抽象隔離并封裝簡化，讓上層用戶專注于應用開發(fā)，不需要承受整個冰山的重量。
結合規(guī)劃設計各層面的具體實踐，接下來要講一講我們自己的實現(xiàn)路徑。首先，在基礎設施層和平臺服務層，面向公有云場景，我們的實踐是基于阿里云容器服務ACK去構建在公有云場景的K8s平臺。
ACK 整合了阿里云虛擬化、存儲、網(wǎng)絡和安全能力，提供高性能可伸縮的容器應用管理能力，支持企業(yè)級容器化應用的全生命周期管理。
ACK當前支持的版本為：1.22.3 和 1.20.11，僅發(fā)布Kubernetes雙數(shù)號的大版本，版本支持策略如下：
集群創(chuàng)建：ACK支持Kubernetes兩個大版本的創(chuàng)建，例如v1.16、v1.18。當新版本Kubernetes發(fā)布時，較老的一個版本將不再開放創(chuàng)建功能。
升級和運維保障：ACK保障最近的三個Kubernetes大版本的穩(wěn)定運行，同時支持最新版本往前兩個大版本的升級功能，例如當前最新版本為v1.20，則ACK支持v1.18、v1.16的升級功能。
工單答疑：ACK僅提供最近的三個Kubernetes大版本的技術支持。
那么，在私有云場景中，我們的建設實踐是采用了VMware的一套技術架構，物理機采用DELL的PowerEdge系列。并在物理機上部署VMware ESXi，通過VMware vCenter Server將多臺物理機資源組成資源池，組成虛擬化管理平臺。
除此之外，在私有發(fā)布場景中，還需要去部署K8s的整個系統(tǒng)，我們選用了青云的KubeKey。
這款開源K8s安裝器項目，可以輕松、高效、靈活地單獨或整體安裝 Kubernetes 和 KubeSphere。
支持的Linux 發(fā)行版本
支持的Kubernetes 版本
使用起來也比較簡單，具體操作如下：
./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
在應用交付層，我們的實踐是基于KubeVela這一引擎來做平臺建設。
KubeVela 作為一個開箱即用的現(xiàn)代化應用交付與管理平臺，使得應用在面向混合云環(huán)境中的交付更簡單、快捷。使用 KubeVela 的軟件開發(fā)團隊，可以按需使用云原生能力構建應用，隨著團隊規(guī)模的發(fā)展、業(yè)務場景的變化擴展其功能，一次構建，隨處運行。
KubeVela 圍繞著云原生應用交付和管理場景展開，背后的應用交付模型是 Open Application Model，簡稱 OAM ，其核心是將應用部署所需的所有組件和各項運維動作，描述為一個統(tǒng)一的、與基礎設施無關的“部署計劃”，進而實現(xiàn)在混合環(huán)境中標準化和高效率的應用交付。
為什么要用 KubeVela？
云原生技術的發(fā)展趨勢正在朝著利用 Kubernetes 作為公共抽象層來實現(xiàn)高度一致的、跨云、跨環(huán)境的的應用交付而不斷邁進。然而，盡管 Kubernetes 在統(tǒng)一底層基礎架構細節(jié)方面表現(xiàn)出色，它并沒有在混合的分布式部署環(huán)境之上提供應用層的軟件交付模型和抽象。我們已經(jīng)看到，這種缺乏統(tǒng)一上層抽象的軟件交付過程，不僅降低了生產(chǎn)力、影響了用戶體驗，甚至還會導致生產(chǎn)中出現(xiàn)錯誤和故障。
然而，為現(xiàn)代微服務應用的交付過程建模是一個高度碎片化且充滿挑戰(zhàn)的事情。到目前為止，絕大多數(shù)試圖解決上述問題的技術方案，要么過于簡單以致于無法覆蓋實際生產(chǎn)使用中的問題，要么過于復雜難以落地使用。云原生帶來的基礎設施能力爆發(fā)式增長也決定了新一代的應用管理平臺不能以硬編碼的方式做能力的集成和 UI 的構建，除了滿足基礎的功能和場景，平臺本身的擴展能力成為了新時代應用管理平臺的核心訴求。這就意味著平臺不僅要簡單易用，還要能夠隨著應用交付和管理的需求復雜度提升能夠不斷擴張，能夠讓開發(fā)者自助式的接入和使用，充分享受云原生生態(tài)的紅利。
這也是 KubeVela 出現(xiàn)的核心價值：它既能夠簡化面向混合環(huán)境（多集群/多云/混合云/分布式云）的應用交付過程；同時又足夠靈活可以隨時滿足業(yè)務不斷高速變化所帶來的迭代壓力。它本身是一個面向混合交付環(huán)境同時又高可擴展的應用交付引擎，滿足平臺構建者的擴展和自建需求；同時又附加了一系列開箱即用的擴展組件，能夠讓開發(fā)者自助式的開發(fā)、交付云原生應用。
KubeVela 核心功能
統(tǒng)一的應用交付模型：KubeVela 創(chuàng)新性的提出了 開放應用模型（OAM）來作為應用交付的頂層抽象，該模型支持交付任意類型的工作負載包括容器、數(shù)據(jù)庫甚至是虛擬機到不同的云和 Kubernetes 集群中。用戶無需關心任何基礎設施細節(jié)，只需要專注于定義和部署應用即可。應用只需要一次編排，就可以隨處運行，免去了適配不同平臺的痛苦。
聲明式交付工作流：KubeVela 的整個交付模型完全是由用戶聲明式驅動的，兼顧用戶體驗和健壯性，其控制循環(huán)能夠有效避免配置漂移，且具備多租權限控制能力。用戶可以通過 CUE 語言（一種源自 Google Borg 系統(tǒng)的數(shù)據(jù)配置語言）自由的根據(jù)需求場景來設計和選用交付工作流中的每一個步驟，滿足業(yè)務快速增長的需求，同時持續(xù)保證生產(chǎn)環(huán)境面向終態(tài)的穩(wěn)定性。
多集群/混合云應用交付控制平面：KubeVela 原生支持豐富的多集群/混合環(huán)境持續(xù)交付策略，也支持跨環(huán)境交付。這些交付策略為你的分布式交付流程提供了充足的效率和安全的保證。KubeVela 提供的中心化管控能力也減輕了到每一個集群去排查問題的負擔，針對不同的平臺提供統(tǒng)一的體驗，為了享受自動化交付的便利，你再也不需要成為 Kubernetes 專家。
KubeVela vs. 傳統(tǒng) PaaS 平臺
傳統(tǒng) PaaS (如 Heroku，Cloud Foundry 等) 提供完整的應用程序部署和管理功能，旨在提高開發(fā)人員的體驗和效率。在這個場景下，KubeVela 也有著相同的目標。
不過，KubeVela 和它們最大的區(qū)別在于其可擴展性。
KubeVela 是可編程的。它的交付工作流乃至整個應用交付與管理能力集都是由獨立的可插拔模塊構成的，這些模塊可以隨時通過編寫 CUE 模板的方式進行增/刪/重定義且變更會即時生效。與這種機制相比，傳統(tǒng)的 PaaS 系統(tǒng)的限制非常多：它們需要對應用類型和提供的能力進行各種約束來實現(xiàn)更好的用戶體驗，但隨著應用交付需求的增長，用戶的訴求就一定會超出 PaaS 系統(tǒng)的能力邊界。這種情況在 KubeVela 平臺中則永遠不會發(fā)生。
此外，KubeVela 是一個獨立于運行時集群的應用交付控制平面（這是我們認為的下一代 PaaS 系統(tǒng)的合理形態(tài)），而現(xiàn)有的 PaaS 則往往選擇以插件形式部署在運行時集群當中。
下面，我們來舉一個最簡單的示例來看一看怎樣將一個應用或服務，能夠快速的在K8s上以容器化的方式運行起來：
交付Helm組件
在交付應用后，我們需要運維該應用來觀測它的指標和日志。
基于此，我們在KubeVela引擎構建云平臺時，在日志、監(jiān)控告警等層面做了相應的自動化的集成。主要的四個方面包括監(jiān)控目標、監(jiān)控面板、日志采集、告警規(guī)則特征上做了相應的開發(fā)。
下圖為監(jiān)控目標特征、監(jiān)控面板特征、日志采集特征、告警規(guī)則特征：
基于前面構建好的底層云平臺系統(tǒng)，最后我們講講它的能力。
由于我們公司核心產(chǎn)品是一個一站式的云原生DataOps平臺，底層的云平臺系統(tǒng)搭載了上層的容器化大數(shù)據(jù)平臺、數(shù)據(jù)集成開發(fā)平臺、數(shù)據(jù)資產(chǎn)運營平臺、數(shù)據(jù)質(zhì)量平臺等各種數(shù)據(jù)平臺系統(tǒng)。
由于核心引擎提供的靈活、可擴展性，未來我們的云平臺還能夠將更多的K8s生態(tài)及系統(tǒng)能力納入進來，向上面的業(yè)務層提供更強大的功能及性能支撐。
具體來說，目前的階段性成果體現(xiàn)在：
大數(shù)據(jù)組件的快速交付：Hive、Spark、HDFS、Kafka、Flink…
數(shù)據(jù)應用的快速開發(fā)集成：自定義程序發(fā)布
統(tǒng)一的可觀測性集成和展示：監(jiān)控、告警、日志
全系統(tǒng)的多租戶實現(xiàn)：租戶配額管理、服務/數(shù)據(jù)的鑒權+授權
未來更進一步向上賦能DataOps的能力則體現(xiàn)在：
開發(fā)運維：CI/CD，多環(huán)境管理
可觀測性：大數(shù)據(jù)平臺全鏈路追蹤
彈性伸縮：大數(shù)據(jù)作業(yè)資源彈性、自適應
增強型調(diào)度：Volcano Scheduler，提供更適合大數(shù)據(jù)系統(tǒng)的使用
