CNStack 2.0:雲原生的技術中臺

語言: CN / TW / HK

在進入千禧年後,隨著計算機技術的發展和業務創新的不斷湧現,許多大公司內的 IT 計算中心也在醞釀著變革。一方面,各部門相對獨立的 IT 管理平臺已經難以滿足日益增長和不斷變化的計算管理需求;另一方面,IT 計算中心也越來越多的成為業務創新的發源地,從一個成本中心向營收來源發展。相應的,一種圍繞著資源和負載管理平臺的技術領域逐漸稱為學術界和產業界的熱點。它在不同的發展階段和不同的應用場景有著不同的名字,從最早的叢集(Cluster),網格(Grid),到後來的資料中心作業系統(DCOS),雲端計算(Cloud Computing)。同時,在資源管理和負載管理這兩大方面也不斷的拓展著自身的邊界。

1.png

目前,以 Kubernetes 為核心代表的雲原生技術逐漸稱為這一領域的主流。它所帶來的不可變基礎設施,以資源為管理物件,描述性的 API,最終一致性等等理念,不僅改變了平臺使用者的習慣,能夠更好的在資源彈性變化的環境中保持業務訪問的連續性;更改變了服務和應用研發人員的思維模式,逐漸以這種雲原生的方式來設計和開發,提高創新效率。

阿里雲有“公共雲”、“專有云”兩種產品形態,使用同樣基於飛天作業系統的技術路線,為使用者提供從伺服器開始一整套資源和負載的管理能力,以及執行在上面的各種服務。與此同時,也有很多客戶由於種種原因無法完全使用公有云服務,也無法採購和部署一整套大專。在基於雲原生的產品領域中,這些客戶或者接觸了 Kubernetes 等開源專案,或者試用過紅帽,Rancher 等廠商提供的 Openshift,Rancher 等平臺產品,甚至體驗了圍繞這些產品構成的整個產品家族生態,如 IBM Cloud Pak 等。他們驚喜與這些雲原生技術帶來的敏捷,開放,韌性等特點。同時,也希望在此基礎上獲得支援不同業務場景的豐富服務,以便快速提升創新能力。

應對這種需求,雲原生 PaaS 團隊經過長時間的技術和經驗積累,歷時近半年的研發,建立了 CNStack 2.0 雲原生技術中臺產品。在接下來的內容裡,將分享在 CNStack 2.0產品,架構,研發中主要的設計思想和心得體會。

產品目標

阿里雲使用雲原生技術在資源和負載管理這一領域的探索已經有一段歷史了。在長期與解決方案團隊,產品團隊,外部客戶的溝通合作中,發現使用者對雲原生技術帶來的以下特點最為關注。

敏捷

敏捷並不簡單的等同於輕量,它更多的代表靈活性和因此而帶來的效率的提升。

使用者希望平臺和服務能夠隨著不同的應用場景和規模,提供不同的部署配置選項。既能夠管理三五臺伺服器,提供一兩種服務或者公共負載型別,也能夠管理百臺伺服器,滿足幾個業務團隊的不同訴求,甚至管理數千上萬臺伺服器,跨越多個地域,支援不同行業線的複雜服務。

針對這些場景和規模的差異,使用者需要的只是做好資源規劃,在部署平臺和服務時,選擇不同的配置選項。無論場景和規模的差異,平臺都會提供一致的使用體驗。同時,所需的管理資源開銷最好能夠隨著規模的增大和功能的增加,對數或者線性級別的增長。此外,使用者也可以很方便的獲取產品,不需要複雜的硬體資源就可以部署和試用,例如公有云申請的伺服器上,甚至是自己的膝上型電腦上。

敏捷還體現在產品功能的組合和升級,可以根據需要,增加和減少功能和服務,以響應不斷變化的創新訴求。

開放

使用者希望能保護已有的技術投資,也希望能方便,快速的補充開源社群或者其他廠商的技術創新。這就需要產品具備開放的特點。這裡的開放主要是指採用具有開源社群生命力的技術框架和標準的協議規範,產品自身也擁有豐富的擴充套件機制。

一個開放的產品,可以讓使用者

  • 方便的獲取技術資料和試用環境,降低學習門檻
  • 通過標準的協議規範和擴充套件機制,整合其他廠商的產品或者被其他廠商產品整合,保護技術投資
  • 支援更多的基礎設施型別和工作負載型別
  • 與開源社群一起不斷髮展,保持技術先進性

生態

技術中臺作為業務創新的核心,需要支援多種業務型別,涵蓋業務創新的生命週期。從微服務框架,中介軟體,到 AI,資料處理;從研發設計,製品管理,到應用釋出,容災高可用;從本地資料中心,到邊緣,公有云。

為了支援如此豐富的能力,需要圍繞技術中臺構建產品生態,建立雲服務,雲元件的標準規範和支援標準規範的工具鏈。

  • 雲服務:通過服務的形式在平臺提供能力擴充套件,可以使用平臺提供的使用者,租戶,鑑權,審計,許可證,多叢集部署,UI 框架等基礎能力,與平臺既有能力或其他服務無縫的協作。和整個平臺的運維一樣,雲服務的生命週期管理由管理員負責。
  • 雲元件:通過部署宣告的方式為平臺使用者提供軟體的部署和運維,所部署的軟體可以和使用者自研軟體一起編排實現業務流程。和使用者自研軟體一樣,雲元件的生命週期管理由具體的使用者負責。

2.png

上述是 CNStack 2.0 當前所支援的雲服務一覽。這些雲服務與平臺自身的釋出完全解耦,阿里雲研發團隊或者合作伙伴可以方便的針對業務場景擴充套件技術中臺能力,獨立釋出雲服務。需要重點強調的是,CNStack 平臺自身也是以雲服務方式開發,運維,管理的。

CNStack 2.0 為雲服務和雲元件的整合,測試和釋出提供了一整套規範的工具鏈,它就是阿里云云原生應用交付平臺(Application Delivery Platform,簡稱 ADP) [ 1] 。CNStack 2.0 自身也是使用 ADP 開發和釋出的。

3.png

在 ADP 平臺上,開發者可以將構成雲服務的元件以 helm charts 的形式上傳。平臺根據研發規範掃描檢查後,以自有元件的形式進行版本管理。此後,開發者可以把這些自有元件和 ADP 平臺上提供的公共研發中介軟體,如資料庫,訊息,微服務框架等一起編排為雲服務,並在指定的公有云環境建立驗證環境,部署 CNStack 2.0(也被稱為底座)一起完成功能測試和一系列驗證,如高可用等,最終打包為雲服務(或者雲元件)。雲服務(雲元件)的釋出包規範遵循雲原生 PaaS 團隊貢獻給社群的 CNCF Sealer 開源專案。交付時,在使用者環境部署的 CNStack 2.0 平臺上,管理員將雲服務(雲元件)釋出包匯入能力中心。在能力中心,管理員可以完成雲服務的部署,升級,變配等一系列生命週期管理。

4.png

安全合規

隨著隱私和資產保護重要性的日益提升,安全合規越來越成為業務創新中必須要解決的問題。作為在企業環境部署的產品,CNStack 2.0 需要滿足嚴格的安全和合規規範。包括但不限於以下方面:

  • 控制管理服務在網路的暴露面,儘量收斂為一個埠,支援符合安全標準的網路隔離規劃
  • 提供使用者管理能力或與現有的使用者管理系統的整合
  • 提供多租戶的隔離能力和靈活的許可權管理
  • 提供與域名相關的證書,金鑰管理或與現有的證書,金鑰管理系統整合
  • 確保加密的網路傳輸和敏感資料的加密儲存
  • 提供審計能力,支援合規檢查
  • 為在平臺執行的服務和應用提供靜態和動態的安全合規掃描

架構設計

為了滿足上述產品目標,研發團隊制定了以下設計原則​

面向 API 開發

與面向 API 開發相對應的是面向 UI 開發。之前,對於產品功能的實現方式經常會聽到類似“白屏”,“黑屏”的稱謂。白屏就是在 UI 實現功能操作,而黑屏指通過命令列實現功能操作。因為功能邏輯通常在 UI 元件完成,就造成了通過命令列實現的功能,缺乏完整能力或者安全合規的要求,所以“黑屏”通常被認為是 hack 的實現。類似這種面向 UI 開發的方法還有很多弊端,無法滿足前文提到的產品目標。

  • 產品設計以 UI 驅動,UI 的調整對功能實現影響大
  • 難以被其他產品或工具鏈整合,侷限於頁面巢狀,難以支援開放性要求
  • 難以建立雲服務,雲元件的規範,提供方便的平臺能力整合接入
  • 功能的實現邏輯分散,呼叫鏈長,難以維護,排查錯誤
  • 認證,鑑權,審計等公共能力無法集中控制,難以保障安全合規

與此相反,在面向 API 開發的架構中,UI 只是 API 能力的一種展示形式,UI 模組的前端或者直接呼叫管理服務 API,或者由 UI 的後端服務封裝一個或多個管理服務 API。但是 UI 的後端服務自身並不實現任何執行期物件的管理能力,只是一個或多個 API 呼叫流程的封裝,以及輸入和輸出資料的整理。

在面向 API 開發的架構中,還有一項重要的設計準則就是:“沒有隱藏的內部 API”(No Hidden Internal API)。這就要求管理服務元件之間的呼叫介面,也是使用者對服務訪問的呼叫介面。只要保證 API 的一致性,服務的元件可以容易的替換,確保產品具有敏捷,開放的能力。此外,它還消除了安全隱患,對所有 API 的呼叫使用一致的認證,鑑權,審計等安全合規能力。

所有管理物件都是資源

以 RESTful API 為代表,圍繞資源進行管理的程式設計模型不僅帶來了使用體驗的提升,也改變了管理元件的實現方式。它將管理物件都作為資源,通過建立和改變資源的宣告來實現管理功能,查詢資源的狀態來了解管理結果。Kubernetes 更是為這種程式設計模型提供了最佳實踐,帶來了具體的實現方法。

在 CNStack 2.0 的架構設計中,採用“所有管理物件都是資源”的程式設計模型,具有以下技術特點和優勢:

  • 宣告式的 API 讓呼叫者無需持續關注和處理管理動作發出後的執行階段,管理服務需要確保管理物件的狀態和資源宣告最終保持一致
  • 宣告式的 API 讓呼叫者無需持續關注和處理管理動作發出後的執行階段,管理服務需要確保管理物件的狀態和資源宣告最終保持一致
  • 建立和改變管理物件的 API 都是非同步的,API 的執行者只需要確保持久化資源的最新聲明後就可以讓 API 返回,簡化 API 的處理,提高響應率
  • 因為一切都是資源,所以 API 執行者的處理可以共同化,方便實現統一的認證,鑑權,審計,篩選,分頁等能力,也易於擴充套件,滿足高可用和韌性的要求
  • 因為一切都是資源,所以 API 客戶端的處理也可以共同化,無論在 UI 還是 CLI 上都是建立和改變管理物件的資源宣告,展示管理物件的資源狀態。
  • 處理資源狀態和宣告一致性(reconcile)的控制器可以獨立實現,與 API 的執行者解耦,便於升級,擴充套件和管理。同時,它的故障不會影響 API 自身的處理,具備可擴充套件,高可用,韌性,敏捷,開放的特點。

將 Kubernetes 作為程式設計框架

Kubernetes 為“所有管理物件都是資源”的程式設計模型提供了最佳實踐,帶來了具體的實現方法。Kubernetes 的 operator 模式,自定義資源(Customized Resource Definition)等能力讓開發者可以方便,快捷的擴充套件功能,由此看來,Kubernetes 不僅僅是一個管理容器化工作負載和服務的編排平臺,更是一個可擴充套件的程式設計框架。

在 CNStack 2.0 的架構設計中,Kubernetes 作為程式設計框架的價值還體現在更多的方面

  • 租戶管理

在共享基礎設施的環境下,管理物件的訪問隔離是一個重要的能力。Kubernetes 提供了“名稱空間”的概念,使用者資源與名稱空間關聯,實現訪問隔離和配額,策略等管理控制。但是,Kubernetes 中的名稱空間並不支援層級關係,基於Hierarchical Namespace Controller (HNC) [ 2] 開源專案,CNStack 2.0 將 Kubernetes 的名稱空間擴充套件至多級。CNStack 2.0 的管理物件大都以 Kubernetes 的資源方式管理,利用層級化的名稱空間實現租戶管理。

  • 許可權管理

Kubernetes 提供了基於角色的訪問控制(RBAC)。其中,角色定義了對 API group,資源和操作的允許範圍。角色可以通過聚合方式靈活的組合。通過將角色和使用者,使用者組,服務賬號以及租戶關聯,可以控制使用者和服務對資源的訪問控制。對於不以 K8s 資源管理的物件,一樣可以通過在角色中對映管理物件API的相關資訊,定義訪問策略,甚至對於無法以資源管理的執行命令,RBAC 也支援 nonresourceurls 的形式。CNStack 2.0 以 Kubernetes 作為許可權控制引擎,將各種管理物件的許可權點(permission)定義為 Kubernetes 的角色,通過 Kubernetes 角色的聚合實現靈活的自定義訪問策略,最終呼叫 SubjectAccessReview API 獲取策略執行結果,判定指定使用者或服務對 API 的訪問許可。

  • API 管理

在“面向 API 開發”的設計原則下,API 是 CNStack 2.0 的核心。Kubernetes 提供了 API 的擴充套件能力,基於自定義資源(Customized Resource Definition)和整套研發框架。開發者只需要專注於自定義資源的執行期管理邏輯,通過 Kubernnetes API 獲取自定義資源的宣告和當前狀態,處理資源宣告和當前狀態的差異,讓它們最終達成一致。同時,將 API 物件宣告的處理,持久化等工作完全交給 Kubernetes 元件。這樣不僅極大的提高了研發效率,也讓整個架構具備敏捷,開放,可擴充套件,韌性的特點。

無論是以 Kubernetes 自定義資源方式實現的 API,還是以其他方式實現的 API,CNStack 2.0 基於 CNCF 的 Emissary-Ingress [ 3]  專案,建立了管理 API 閘道器,實現了管控 API 統一的路由,認證,鑑權,審計等能力。管控API閘道器收斂所有管控 API 對外暴露的訪問點為一個埠,允許管理服務,或者雲服務(雲元件)開發人員以 Kubernetes 自定義資源宣告的方式描述API的路由,認證,鑑權和審計要求。這種方法大幅降低產品的被攻擊面,也降低了管理服務,雲服務(雲元件)的研發負擔。

  • 證書管理

X.509 證書被應用於數字安全的方方面面,例如 HTTPS 安全通訊。和域名一樣,證書有規範的頒佈機制,例如適用於 PoC 或私有範圍使用的自頒發;抑或是基於使用者從認證的頒佈機構獲取的根證書(BYOK:Bring You Own Key),甚至是使用者有自己的證書管理平臺,如 Vault。Kubernetes 有內建的證書資源,可以基於自身的根證書根據使用者請求建立證書。CNCF 的 cert-manager [ 4] 專案,以 Kubernetes 自定義資源的方式,提供了更全面的證書管理能力,支援上述多種場景。CNStack 2.0 基於 cert-manager,建立了證書管理服務。建立的證書可以自動的應用與管理服務和使用者自建服務的安全通訊。

  • 災備恢復管理

因為“所有管理物件都是資源”,所以管理物件的持久化都以資源的形式儲存在Kubernetes 中。基於開源專案 Velero [ 5] ,CNStack 2.0 建立了備份恢復服務,允許管理人員以 Kubernetes 自定義資源宣告的方式說明備份策略,如週期,資源型別,範圍,備份源等,以及恢復策略。

  • 多叢集管理

CNStack 2.0 天生就需要支援多叢集,以滿足使用者對不同場景的訴求,例如資源和負載的物理隔離,多地域部署,容災多活等。基於 Kubernetes,雲原生 PaaS 團隊和紅帽等技術夥伴開源了 CNCF Open Cluster Management(OCM) [ 6] 專案。基於 OCM,CNStack 2.0 建立了多叢集的建立,納管等生命週期管理服務,作為“多叢集服務”這一雲服務。它允許使用者以 Kubernetes 自定義資源宣告的方式描述需要建立或者納管的叢集。在“多叢集服務”的幫助下,雲服務(雲元件)也支援多叢集下的部署和管理,區分管理面和資料面元件,並宣告部署的叢集選擇條件。同時,對租戶的資源控制,配額,管理策略等也擴充套件至多叢集。

安全無處不在

安全合規是產品需求的一個重要方面,它體現在架構設計的方方面面。

  • 管控 API 統一收斂到管理 API 閘道器,最小化攻擊面,所有的 API 訪問都需要完成認證,鑑權,審計,沒有後臺 API
  • 管控 API 統一收斂到管理 API 閘道器,最小化攻擊面,所有的 API 訪問都需要完成認證,鑑權,審計,沒有後臺 API
  • 服務根據訪問需求設定擁有最小化訪問許可權的角色
  • 所有的網路通訊都是加密的,安全通訊證書統一管理,實現自動的更替
  • 所有的敏感資料都以 secret 方式加密儲存
  • 所有管理和輸出元件都需要經過 ADP 元件上架標準流程,完成映象和執行期掃描檢查
  • 節點和叢集的納管以零信任為前提,實現管理和被管理物件的雙向認證

CNStack 2.0 架構

CNStack 2.0 圍繞 Kubernetes 為程式設計框架,它的管控元件大都以 Kubernetes 控制器的方式實現,以 Kuberentes API 擴充套件作為管控 API。其中,主要的元件如下

  • ACK Distro

ACK Distro 是雲原生 PaaS 團隊和公有云 ACK 團隊一起釋出的阿里雲 Kubernetes 發行版。它以 Sealer 為釋出和部署工具,支援在眾多異構環境中部署和運維 Kubernetes 叢集。其中 Kubernetes 核心元件和公有云 ACK 上的 Kubernetes 核心元件一致,經歷了嚴格的安全檢查和調優。所包含的網路(Hybridnet [ 7] ),儲存(Open-Local [ 8] )元件也是雲原生 PaaS 團隊和其他阿里雲,螞蟻基礎設施團隊共同研發的開源專案,經歷了內部長時間的驗證。ACK Distro 構成了 CNStack 2.0 的 Kubernetes 基礎。

  • cn-app-operator

cn-app-operator 是雲服務,雲元件生命週期的管理者。在內部,它基於 OAM 的設計思想,支援 helm 作為 Kubernetes 資源的渲染引擎,圍繞雲服務和雲元件的釋出包,例項,自運維策略,告警管理建立了一系列 Kubernetes 自定義資源實現管理能力。它也是後續雲原生 PaaS 團隊計劃開源的一個專案。

  • Account Mgr

Account Mgr 實現使用者的賬號管理或者對接支援標準協議,如 LDAP,AD 等的使用者管理系統整合。它也負責使用者和雲服務的認證,建立訪問憑證。Accout Mgr 包含開源專案 KeyCloak [ 9]  實現使用者的賬號管理。

  • UI Backend

UI Backend 是 UI 訪問的後臺服務,它只是 Kubernetes API 或者其他管理服務 API 的封裝。在內部訪問其他管理服務API時一樣通過 Management Gateway 呼叫。

  • 審計/日誌/監控/告警

審計/日誌/監控/告警元件對平臺管理元件,雲服務/雲元件,基礎設施提供審計,日誌,監控,告警服務。它基於 Loki [ 10] 和 Victoria Metrics [ 11] Grafana [ 12]  實現日誌和監控指標的採集,儲存,查詢和展示。其中,審計資訊來自 Management Gateway 上對 API 的分析處理。

  • 管理元件

CNStack 2.0 的眾多管理元件都是以 Kubernetes Controller 的方式實現,通過 Kubernetes 自定義資源的方式提供 API。

  • Management Gateway

Management Gateway 是 CNStack 2.0 的一個核心元件,它負責所有管控 API 的路由,認證,鑑權,審計,加密傳輸等能力。Management Gateway 基於 Emissary-Ingress [ 13] ,並在之上實現了認證,鑑權等一系列 filter 外掛。

  • Ingress

Ingress 在 CNStack 2.0 中負責處理資料瀏覽,例如日誌,監控指標在多叢集間的收集。也負責雲服務在管控叢集部署的管理面元件和在被管理叢集上部署的資料面元件之間的資料傳輸。

CNStack 2.0 的網路通訊設計以暴露面最小化為原則,所有管控 API 收斂在 Management Gateway,資料訪問收斂在 Ingress。在多叢集環境下,對被管理叢集的訪問通過雲原生 PaaS 團隊開源的 Cluster Gateway [ 14] 專案實現,具備路由透明,許可權一致,通訊安全的能力。管控叢集對被管理叢集 ingress 的訪問,以及被管理叢集對管控叢集 Management Gateway 和 Ingress 的訪問都通過 Kuberetes Headless Service 實現路由,遮蔽網路聯通的複雜性。

CNStack 2.0 還包含眾多的雲服務,例如提供微服務應用釋出,監控,運維,高可用等能力的應用管理服務;提供共享儲存服務的 VCNS-OSS;提供虛擬機器型別工作負載管理的虛擬化服務;提供邊緣場景資源,裝置和工作負載管理的雲邊協同服務;提供雲原生服務網格能力的服務網格服務,等等。它們的能力和架構設計會在後續專文介紹。03

研發提效

CNStack 2.0 是一個包含多個雲服務的產品集合。一個有效的研發流程以及相關的整合,測試工具鏈很大程度上影響著產品的研發效率和品質,並最終左右產品在市場上的口碑和表現。不存在一個完美的研發流程和相關工具,而是根據人員,環境和產品需求不斷演進和迭代的。在 CNStack 2.0 的開發過程中,研發團隊收穫了以下經驗。

論每日構建的重要性

每日構建是指在每天晚上或者早上的時候,將產品的各個元件編排為完整產品,在模擬環境完成部署和驗證,並建立可釋出的版本。是否能完成每日構建是產品研發效率和品質的一個比較好的衡量標準,從一定程度上也說明了產品部署的靈活和易用性。每日構建在研發過程中具有很重要的價值,包括

  • 及時獲取最新的穩定產品釋出包,為相關雲服務的整合,測試建立工作基礎
  • 及時發現元件整合或者服務整合的問題,這些在元件或者服務自身的開發過程中是難以發現的
  • 模擬產品交付的實際場景,讓演練成為日常工作

5.png

上圖是 CNStack 2.0 雲服務每日構建的概念流程,其中元件的研發人員在日常開發中將映象和部署配置,例如 helm charts 等,提交到 git repo 或者內部映象倉庫。當每日構建觸發時,建立映象和部署配置的快照,編排為產品並自動部署和測試,測試通過後完成產品釋出。

6.png

ADP 平臺提供了產品編排,驗證環境建立,產品部署等能力。如上圖所示,雲原生 PaaS 團隊基於 ADP 和 Chorus 構建了從開發,整合到測試,釋出一整套流水線機制。

  1. 每日構建觸發時,Chorus Job 記錄當前配置倉庫的 commit-id,並將元件上傳至 ADP 平臺,更新 latest 標識的產品版本,完成產品整合。
  2. 此後,呼叫 ADP API 在公有云建立測試環境,並部署產品。通過產品內建的測試 Job 完成自動化測試,並收集測試報告,傳送到指定的 IM 平臺(如釘釘,郵件群等)完成產品測試。
  3. 產品釋出負責人根據測試報告,判定本次構建是否滿足釋出要求。如果滿足,在 ADP 平臺根據 Semantic Version 規範,完成產品釋出。在日常可以以日期作為釋出版本的 Patch Version,在產品預釋出階段可以以 RC 作為 Patch Version。

  4. 每日構建觸發時,Chorus Job 記錄當前配置倉庫的 commit-id,並將元件上傳至 ADP 平臺,更新 latest 標識的產品版本,完成產品整合。

吃自己的狗糧

阿里雲 ADP 平臺作為 CNStack 2.0 的一部分,不僅負責雲服務/雲元件的編排和釋出,同時也負責雲服務/雲元件的整合和測試。CNStack 2.0 基礎平臺自身也是由 ADP 完成編排,釋出和整合,測試的。另一方面,ADP 也基於 CNStack 2.0 基礎平臺為雲服務/雲元件建立測試環境,組裝釋出包。在服務第三方雲服務/雲元件研發團隊的同時,也在服務自身,吃自己的狗糧。

“吃自己的狗糧”讓 CNStack 2.0 產研團隊能夠和使用者感同身受,切身體會到產品在易用性和功能上的差距。在產品研發的過程中,很多需求和問題的發現都來自產研團隊自身。

為自己的研發效率負責

研發提效關係到每個研發,測試工程師自身的工作倖福感。以雲原生技術驅動的 CNStack 2.0 和相關的工具鏈提供了豐富的 API 和可擴充套件能力。雲原生社群也有一系列可供整合使用的開源專案。在雲原生技術流行的時代,工程師需要保持不斷學習的精神,挖掘和建立能夠提升自身工作效率的方法和工具,為自己的研發效率負責。

相關資料

CNStack 產品官網

https://www.aliyun.com/activity/middleware/cnstack

CNStack 社群版(免費下載使用)

https://github.com/alibaba/CNStackCommunityEdition

ADP 產品官網

https://help.aliyun.com/product/191542.html

ACK Distro

https://github.com/AliyunContainerService/ackdistro

CNCF Sealer 專案

https://github.com/sealerio/sealer

CNCF OCM 專案

https://open-cluster-management.io/

相關連結

[1] 阿里云云原生應用交付平臺(Application Delivery Platform,簡稱 ADP)https://www.aliyun.com/product/aliware/adp

[2] Hierarchical Namespace Controller (HNC) 

https://github.com/kubernetes-sigs/hierarchical-namespaces

[3] Emissary-Ingress

https://www.cncf.io/projects/emissary-ingress/

[4] cert-manager

https://www.cncf.io/projects/cert-manager/

[5] Velero

https://velero.io/

[6] Open Cluster Management(OCM)

https://open-cluster-management.io/

[7] Hybridnet

https://github.com/alibaba/hybridnet

[8] Open-Local

https://github.com/alibaba/open-local

[9] KeyCloak

https://github.com/keycloak/keycloak

[10] Loki 

https://github.com/grafana/loki

[11] Victoria Metrics

https://github.com/VictoriaMetrics/VictoriaMetrics

[12] Grafana

https://github.com/grafana/grafana

[13] Emissary-Ingress

https://www.cncf.io/projects/emissary-ingress/

[14] Cluster Gateway

https://github.com/oam-dev/cluster-gateway

點選此處,檢視 CNStack 產品官網詳情