伴隨著數字化轉型腳步的加快，大數據已成為企業經營管理的主要手段之一，越來越多的行業也選擇通過大數據來實現業績增長。今年年初，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容器編排的各種特性，例如容器運行時/網絡/存儲接口、故障自動遷移、彈性伸縮、租戶控制等。

針對以上三個方面的設計規劃，其現狀及問題包括：

(1) IaaS層：最主要的是管理成本的權衡：公有云搭建最快，具備公有云產品使用的能力即可，管理成本相對較低，但產品價格很貴；私有云需要有虛擬化平臺建設及運維的能力，管理成本相對較高；混合云前兩者的能力都需要，還需要具備網絡基礎設施建設的能力，管理成本最高。

(2) PaaS層：官方開源版本無任何定制，但要構建一套完整的生態系統，需要自行搭建例如倉庫、監控、報警、日志、負載均衡等額外的系統，技術選型可控但對團隊能力要求高；發行版一般提供一套比較完備的生態系統，但技術選型往往不可控，容易被綁定，另外難以滿足自定義需求的時候，還是需要自行建設；除此之外，K8s的版本發布非常快，如果想用新的特性或者修復bug，需要跟上新版本，但底層平臺升級往往是非常吃力且容易出事故的。

(3) 應用交付：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 <nodeName> -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...
• 數據應用的快速開發集成：自定義程序發布
• 統一的可觀測性集成和展示：監控、告警、日志
• 全系統的多租戶實現：租戶配額管理、服務/數據的鑒權+授權

未來更進一步向上賦能DataOps的能力則體現在：

• 開發運維：CI/CD，多環境管理
• 可觀測性：大數據平臺全鏈路追蹤
• 彈性伸縮：大數據作業資源彈性、自適應
• 增強型調度：Volcano Scheduler，提供更適合大數據系統的使用

作者介紹

金津，智領云科技云平臺研發經理，華中科技大學計算機系碩士。加入智領云6年多，長期從事云原生、容器化編排領域研發工作，主導了智領云自研的BDOS應用云平臺產品開發，并在多個大規模項目中成功實施落地，在大規模容器化編排系統方向有豐富的實踐經驗。