作者：金津，智領雲科技雲平台研發經理，華中科技大學計算機系碩士。加入智領雲6年多，長期從事雲原生、容器化編排領域研發工作，主導了智領雲自研的BDOS應用雲平台産品開發，并在多個大規模項目中成功實施落地，在大規模容器化編排系統方向有豐富的實踐經驗。
伴随着數字化轉型腳步的加快，大資料已成為企業經營管理的主要手段之一，越來越多的行業也選擇通過大資料來實作業績增長。今年年初，CNCF中國區總監陳澤輝在2022雲原生超級英雄會上表示，Kubernetes (K8s)已無處不在，越來越多的人在使用雲原生和Kubernetes。資料時代，企業如何讓雲原生大資料平台借力K8s以發揮最大價值，今天我們就跟着智領雲科技雲平台研發經理Jason一起來深入了解一下。
一、背景介紹
什麼叫雲原生架構
并不是運作在雲主機上的程式或者容器化的程式就是雲原生程式。
過去十年，随着雲計算的發展，雲原生技術架構逐漸被更多的科技企業采納和應用，其概念可歸納為以下幾點：
Containerization：可運作代碼必須容器化釋出
Dynamic management：動态配置服務，按使用量付費
Micro-service：使用類似于K8s的雲作業系統面向資源池釋出和運維微服務，而不是自己面向節點操作
Orchestration: 使用底層雲平台作業系統的分布式管理體系，而不是自己獨立管理
Automation: 大部分運維操作由代碼完成，而不是手工操作
雲原生架構的優勢
使用雲原生架構帶來的好處很多，其優勢歸納起來大概可以有以下幾點：多租戶、按需擴容、高效疊代、降低成本，以及安全性和合規性。
智領雲聯合創始人 & CEO彭鋒博士曾以Twitter公司為例，強調雲原生架構的優勢。
“Twitter從2011年開始建設自己内部的私有雲平台，我們看到的是業務開發效率數量級的增長，同時避免了部門牆，避免了資料孤島和應用孤島（因為都必須遵守雲平台和其上的大資料平台的釋出規範）。從80台機器的Hadoop叢集，到8000台機器的全局資料平台，在統一叢集中不斷擴充資料能力矩陣，支撐業務營運。很多資料能力建設的工作，也因為應用的雲原生化成為可能。”
對比企業在使用傳統大資料平台時遇到的困難和難點，雲原生架構的優勢便能夠更好地凸顯出來。那麼，雲原生架構又是如何解決這些難點，成為如今大資料平台搭建的市場趨勢呢？
傳統大資料平台的難點，主要展現在其元件安裝運維複雜：
- 每個大資料元件都有自己的安裝流程，系統要求，第三方庫支援要求
- 獨立的分布式管理，高可用，容錯，日志，授權，鑒權機制
- 難以實作對于多租戶，資源隔離，審計，計費的支援
- 工具體系複雜，無法支援CI/CD，系統測試，品質控制
- 無法實作大資料元件及應用的混合排程，資源使用率低
是以，資料應用的開發流程及管理散布在各個系統元件中，缺乏統一全局的管理，開發營運效率低。
傳統大資料平台存在的問題，已經逐漸無法支撐資料驅動業務營運更為豐富的需求，是以呈現出來的市場趨勢就是大資料平台的雲原生化。具體來看：
- K8s基本已成為雲平台的标配，我們隻需要适配K8s即可
- 新的大資料元件更多的以雲原生的方式釋出
- Hadoop會被雲原生存儲+資源排程取代，現有Hadoop叢集的工作負載需要遷移
- 原始的大資料平台已經建設完畢，DataOps的需求出現
- 雲原生應用的普及，資料源逐漸标準化，線上內建處理成為可能
- 數字化轉型需要低門檻，低代碼的自助型平台
二、規劃設計
接下來，我們要讨論的是怎樣規劃設計這樣的雲平台系統，這部分可以從基礎設施層（IaaS）、平台服務層(PaaS)，以及應用傳遞層來看，而每個層面都需要結合目前的業務規模和需求來權衡一些問題，比如
- IaaS：基礎設施管理成本的權衡
- PaaS：K8s的版本管理、監控告警日志內建
- 應用傳遞：如何隔離容器編排層的複雜概念，專注于應用開發
我們的目标是要去傳遞一個K8s雲平台，需求可以先拆分為以下三大方面：
首先，IaaS 層的建設，我們要決定是托管在公有雲，還是自建私有雲，或者是最複雜的混合雲架構；
其次，PaaS 層的建設，我們要決定是用原生的K8s，還是發型版的K8s（各公有雲廠商的K8s服務，或者像Kubesphere、Rancher、OpenShift這些面向私有釋出的發行版等）；
最後是應用傳遞的體系，我們的目的不是為了搭建K8s而搭建，傳遞了K8s平台之後，更重要的是如何快速、靈活地将業務系統“搬”到K8s平台上來，并在未來能夠充分利用好K8s容器編排的各種特性，例如容器運作時/網絡/存儲接口、故障自動遷移、彈性伸縮、租戶控制等。
針對以上三個方面的設計規劃，其現狀及問題包括：
IaaS層：最主要的是管理成本的權衡，公有雲搭建最快，具備公有雲産品使用的能力即可，管理成本相對較低，但産品價格很貴；私有雲需要有虛拟化平台建設及運維的能力，管理成本相對較高；混合雲前兩者的能力都需要，還需要具備網絡基礎設施建設的能力，管理成本最高。
PaaS層：官方開源版本無任何定制，但要建構一套完整的生态系統，需要自行搭建例如倉庫、監控、報警、日志、負載均衡等額外的系統，技術選型可控但對團隊能力要求高；發行版一般提供一套比較完備的生态系統，但技術選型往往不可控，容易被綁定，另外難以滿足自定義需求的時候，還是需要自行建設；除此之外，K8s的版本釋出非常快，如果想用新的特性或者修複bug，需要跟上新版本，但底層平台更新往往是非常吃力且容易出事故的。
應用傳遞：K8s的優勢是容器化編排能力很強，一開始看上去像海面上一座優美的小島；劣勢是它的系統架構、概念原理、管理使用非常複雜，等深入了解了之後才發現小島原來隻是露出海面的冰山一角；對于應用開發者來說，平台工程師應該把容器編排層的能力抽象隔離并封裝簡化，讓上層使用者專注于應用開發，不需要承受整個冰山的重量。
三、實作路徑
結合規劃設計各層面的具體實踐，接下來要講一講我們自己的實作路徑。
首先，在基礎設施層和平台服務層，面向公有雲場景，我們的實踐是基于阿裡雲容器服務ACK去建構在公有雲場景的K8s平台。
ACK 整合了阿裡雲虛拟化、存儲、網絡和安全能力，提供高性能可伸縮的容器應用管理能力，支援企業級容器化應用的全生命周期管理。
ACK目前支援的版本為：1.22.3 和 1.20.11，僅釋出Kubernetes雙數号的大版本，版本支援政策如下：
叢集建立：ACK支援Kubernetes兩個大版本的建立，例如v1.16、v1.18。當新版本Kubernetes釋出時，較老的一個版本将不再開放建立功能。
更新和運維保障：ACK保障最近的三個Kubernetes大版本的穩定運作，同時支援最新版本往前兩個大版本的更新功能，例如目前最新版本為v1.20，則ACK支援v1.18、v1.16的更新功能。
工單答疑：ACK僅提供最近的三個Kubernetes大版本的技術支援。
那麼，在私有雲場景中，我們的建設實踐是采用了VMware的一套技術架構，實體機采用DELL的PowerEdge系列。
并在實體機上部署VMware ESXi，通過VMware vCenter Server将多台實體機資源組成資源池，組成虛拟化管理平台。
除此之外，在私有釋出場景中，還需要去部署K8s的整個系統，我們選用了青雲的KubeKey。
這款開源K8s安裝器項目，可以輕松、高效、靈活地單獨或整體安裝 Kubernetes 和 KubeSphere。
支援的Linux 發行版本
- Ubuntu 16.04, 18.04, 20.04
- Debian Buster, Stretch
- CentOS/RHEL 7
- SUSE Linux Enterprise Server 15
支援的Kubernetes 版本
- v1.17: v1.17.9
- v1.18: v1.18.6
- v1.19: v1.19.8
- v1.20: v1.20.6
- v1.21: v1.21.5 (default)
- v1.22: v1.22.1
使用起來也比較簡單，具體操作如下：
- 建立叢集
./kk create cluster -f config.yaml
- 添加節點
./kk add nodes -f config.yaml
- 删除節點
./kk delete node
-f config.yaml
- 删除叢集
./kk create cluster -f config.yaml
在應用傳遞層，我們的實踐是基于KubeVela這一引擎來做平台建設。
KubeVela 作為一個開箱即用的現代化應用傳遞與管理平台，使得應用在面向混合雲環境中的傳遞更簡單、快捷。使用 KubeVela 的軟體開發團隊，可以按需使用雲原生能力建構應用，随着團隊規模的發展、業務場景的變化擴充其功能，一次建構，随處運作。
KubeVela 圍繞着雲原生應用傳遞和管理場景展開，背後的應用傳遞模型是 Open Application Model，簡稱 OAM ，其核心是将應用部署所需的所有元件和各項運維動作，描述為一個統一的、與基礎設施無關的“部署計劃”，進而實作在混合環境中标準化和高效率的應用傳遞。
為什麼要用 KubeVela？
雲原生技術的發展趨勢正在朝着利用 Kubernetes 作為公共抽象層來實作高度一緻的、跨雲、跨環境的應用傳遞而不斷邁進。然而，盡管 Kubernetes 在統一底層基礎架構細節方面表現出色，它并沒有在混合的分布式部署環境之上提供應用層的軟體傳遞模型和抽象。我們已經看到，這種缺乏統一上層抽象的軟體傳遞過程，不僅降低了生産力、影響了使用者體驗，甚至還會導緻生産中出現錯誤和故障。
然而，為現代微服務應用的傳遞過程模組化是一個高度碎片化且充滿挑戰的事情。到目前為止，絕大多數試圖解決上述問題的技術方案，要麼過于簡單以至于無法覆寫實際生産使用中的問題，要麼過于複雜難以落地使用。雲原生帶來的基礎設施能力爆發式增長也決定了新一代的應用管理平台不能以寫死的方式做能力的內建和 UI 的建構，除了滿足基礎的功能和場景，平台本身的擴充能力成為了新時代應用管理平台的核心訴求。這就意味着平台不僅要簡單易用，還要能夠随着應用傳遞和管理的需求複雜度提升來不斷擴張，讓開發者自助式的接入和使用，充分享受雲原生生态的紅利。
這也是 KubeVela 出現的核心價值：它既能夠簡化面向混合環境（多叢集/多雲/混合雲/分布式雲）的應用傳遞過程；同時又足夠靈活可以随時滿足業務不斷高速變化所帶來的疊代壓力。它本身是一個面向混合傳遞環境同時又高可擴充的應用傳遞引擎，滿足平台建構者的擴充和自建需求；同時又附加了一系列開箱即用的擴充元件，能夠讓開發者自助式的開發、傳遞雲原生應用。
KubeVela 核心功能
統一的應用傳遞模型：KubeVela 創新性地提出了開放應用模型（OAM）來作為應用傳遞的頂層抽象，該模型支援傳遞任意類型的工作負載包括容器、資料庫甚至是虛拟機到不同的雲和 Kubernetes 叢集中。使用者無需關心任何基礎設施細節，隻需要專注于定義和部署應用即可。應用隻需要一次編排，就可以随處運作，免去了适配不同平台的痛苦。
聲明式傳遞工作流：KubeVela 的整個傳遞模型完全是由使用者聲明式驅動的，兼顧使用者體驗和健壯性，其控制循環能夠有效避免配置漂移，且具備多租權限控制能力。使用者可以通過 CUE 語言（一種源自 Google Borg 系統的資料配置語言）自由的根據需求場景來設計和選用傳遞工作流中的每一個步驟，滿足業務快速增長的需求，同時持續保證生産環境面向終态的穩定性。
多叢集/混合雲應用傳遞控制平面：KubeVela 原生支援豐富的多叢集/混合環境持續傳遞政策，也支援跨環境傳遞。這些傳遞政策為你的分布式傳遞流程提供了充足的效率和安全的保證。KubeVela 提供的中心化管控能力也減輕了到每一個叢集去排查問題的負擔，針對不同的平台提供統一的體驗，為了享受自動化傳遞的便利，你再也不需要成為 Kubernetes 專家。
KubeVela vs. 傳統 PaaS 平台
傳統 PaaS (如 Heroku，Cloud Foundry 等) 提供完整的應用程式部署和管理功能，旨在提高開發人員的體驗和效率。在這個場景下，KubeVela 也有着相同的目标。
不過，KubeVela 和它們最大的差別在于其可擴充性。
KubeVela 是可程式設計的。它的傳遞工作流乃至整個應用傳遞與管理能力集都是由獨立的可插拔子產品構成的，這些子產品可以随時通過編寫 CUE 模闆的方式進行增/删/重定義且變更會即時生效。與這種機制相比，傳統的 PaaS 系統的限制非常多：它們需要對應用類型和提供的能力進行各種限制來實作更好的使用者體驗，但随着應用傳遞需求的增長，使用者的訴求就一定會超出 PaaS 系統的能力邊界。這種情況在 KubeVela 平台中則永遠不會發生。
此外，KubeVela 是一個獨立于運作時叢集的應用傳遞控制平面（這是我們認為的下一代 PaaS 系統的合理形态），而現有的 PaaS 則往往選擇以插件形式部署在運作時叢集當中。
下面，我們來舉一個最簡單的示例來看一看怎樣将一個應用或服務，能夠快速的在K8s上以容器化的方式運作起來：
傳遞Helm元件
在傳遞應用後，我們需要運維該應用來觀測它的名額和日志。
基于此，我們在KubeVela引擎建構雲平台時，在日志、監控告警等層面做了相應的自動化的內建。主要的四個方面包括監控目标、監控面闆、日志采集、告警規則特征上做了相應的開發。
下圖為監控目标特征、監控面闆特征、日志采集特征、告警規則特征：
四、向上賦能
基于前面建構好的底層雲平台系統，最後我們講講它的能力。
由于我們公司核心産品是一個一站式的雲原生DataOps平台，底層的雲平台系統搭載了上層的容器化大資料平台、資料內建開發平台、資料資産營運平台、資料品質平台等各種資料平台系統。
- 從應用傳遞的角度，雲平台賦能了資料平台的大資料及各種中間件快速容器化內建落地，例如典型的離線計算平台開源元件Hive、Spark、HDFS以及流處理平台開源元件Kafka、Flink等
- 從多租戶的角度，雲平台賦能了資料平台的多租戶管理，例如資源配額管理、鑒權、授權等
- 從彈性的角度，雲平台賦能了資料平台服務的彈性伸縮，以及叢集級别的伸縮等
- 從排程的角度，雲平台賦能了資料平台服務的K8s原生排程（Spark on K8s），以及增強型排程架構如Volcano的內建等
由于核心引擎提供的靈活、可擴充性，未來我們的雲平台還能夠将更多的K8s生态及系統能力納入進來，向上面的業務層提供更強大的功能及性能支撐。
- 大資料元件的快速傳遞：Hive、Spark、HDFS、Kafka、Flink...
- 資料應用的快速開發內建：自定義程式釋出
- 統一的可觀測性內建和展示：監控、告警、日志
- 全系統的多租戶實作：租戶配額管理、服務/資料的鑒權+授權
- 開發運維：CI/CD，多環境管理
- 可觀測性：大資料平台全鍊路追蹤
- 彈性伸縮：大資料作業資源彈性、自适應
- 增強型排程：Volcano Scheduler，提供更适合大資料系統的使用