作者 | 孫健波（天元）  阿里巴巴技術專家

本文整理自 11 月 21 日社群分享，每月 2 場高質量分享，[**點選加入**](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247486796&idx=2&sn=92f50d7b073e2866d96d7fd0ae519196&chksm=fae50683cd928f959e80744061cb6b731cbe16dfadaf65f003a0772a06104b6385ddaf068d2d&scene=21#wechat_redirect)社群。

早在 2011 年，阿里巴巴內部便開始了應用容器化，當時最開始是基於 LXC 技術構建容器，然後逐漸切換到 Docker，自研了大規模編排排程系統。到了 2018 年，我們團隊依託 K8s 體系開始推進“輕量級容器化”，同時投入了工程力量跟開源社群一起解決了諸多規模與效能問題，從而逐步將過去“類虛擬機器”的運維鏈路和阿里巴巴整體應用基礎設施架構升級到了雲原生技術棧。

到了 2019 年，Kubernetes 基礎設施底盤在阿里巴巴經濟體中已經覆蓋了阿里巴巴方方面面的業務，規模化的接入了包括核心電商、物流、金融、外賣、搜尋、計算、AI 等諸多頭部網際網路場景。這套技術底盤，也逐步成為了阿里巴巴支撐 618、雙11 等網際網路級大促的主力軍之一。

目前，阿里巴巴與螞蟻金服內部執行了數十個超大規模的 K8s 叢集，其中最大的叢集約 1 萬個機器節點，而其實這還不是能力上限。每個叢集都會服務上萬個應用。在阿里雲 Kubernetes 服務（ACK）上，我們還維護了上萬個使用者的 K8s 叢集，這個規模和其中的技術挑戰在全世界也是首屈一指的。

## 我們的 Kubernetes 面臨的新挑戰

在規模和效能等基礎設施領域問題逐步解決的同時，規模化鋪開 Kubernetes 的過程中，我們逐步發現這套體系裡其實還有很多意想不到的挑戰。這也是今天分享的主題。

第一個是 **K8s 的 API 裡其實並沒有“應用”的概念**

而且，Kubernetes API 的設計把研發、運維還有基礎設施關心的事情全都糅雜在一起了。這導致研發覺得 K8s 太複雜，運維覺得 K8s 的能力非常凌亂、零散，不好管理，只有基礎設施團隊（也就是我們團隊）覺得 Kubernetes 比較好用。但是基礎設施團隊也很難跟研發和運維解釋清楚 Kubernetes 的價值到底是什麼。

我們來看個實際的例子。

![](http://img.blog.itpub.net/blog/2019/11/23/c78001b0bf19237a.png?x-oss-process=style/bb)

就拿上圖中的 replica 為 3 來說，開發人員怎麼知道例項數應該配幾個呢？如果運維想要改replica，敢不敢改？能不能改？如果 replica 還能理解的話，那像 shareProcessNamespace 這種欄位真是靈魂拷問了。 開發人員僅從字面意思知道這個可能跟容器程式共享有關，那麼配置了這個應用會有什麼影響呢？會不會有安全問題？

在阿里巴巴內部，很多 PaaS 平臺只允許開發填 Deployment 的極個別欄位。為什麼允許填的欄位這麼少？是平臺能力不夠強嗎？其實不是的，本質原因在於業務開發根本不想理解這眾多的欄位。

所以這個 PaaS 平臺只允許使用者填個別欄位，其實反倒是幫助業務開發人員避免了這些靈魂拷問。但反過來想，遮蔽掉大量欄位真的就解決問題了嗎？這種情況下，整個組織的基礎設施能力還如何演進？應用開發和應用運維人員的訴求又該怎麼傳遞給基礎設施呢？

實際上，歸根到底，Kubernetes 是一個 Platform for Platform 專案，它的設計是給基礎設施工程師用來構建其他平臺用的（比如 PaaS 或者 Serverless），而不是直面研發和運維同學的。從這個角度來看，Kubernetes 的 API，其實可以類比於 Linux Kernel 的 System Call，這跟研發和運維真正要用的東西（Userspace 工具）完全不是一個層次上的。你總不能讓本來寫 Java Web 的同學每天直接呼叫著 Linux Kernel System Call，還給你點贊吧？

第二， **K8s 實在是太靈活了，外掛太多了，各種人員開發的 Controller 和 Operator 也非常多**。

這種靈活性，讓我們團隊開發各種能力很容易，但也使得對於應用運維來說， K8s 的這些能力管理變得非常困難。比如一個環境裡的不同運維能力，實際上有可能是衝突的。

我們來看一個例子，基礎設施團隊最近開發上線了一個新的外掛，叫做 CronHPA，一個具體的 Spec 如下所示。

![](http://img.blog.itpub.net/blog/2019/11/23/8e15998dc5fda7ba.png?x-oss-process=style/bb)
作為基礎設施團隊，我們覺得這種 K8s 外掛很簡單， CRD 也很容易理解。就像這個 CronHPA 的功能，從早上六點開始到下午七點鐘這個例項最少有 20 個、最多有 25 個，到第二天早上六點鐘最少 1 個、最多有 9 個，在每個階段會根據 CPU 這個指標衡量調整例項數。

然而，就在我們美滋滋的上線這個外掛後不久，應用運維同學就開始跟我們抱怨了：

1. “這個能力到底該怎麼使用呢？它的使用手冊在哪裡？是看 CRD 還是看文件呢？”
1. “我怎麼知道這個外掛在某個叢集裡有沒有裝好呢？”
1. “我們運維不小心把 CronHPA 和 HPA 繫結給同一個應用，結果發現這個應用是會抽風的。為什麼你們 K8s 非要等到這種衝突發生的時候才報錯呢？你們就不能設計個機制自動檢查一下這些外掛的使用過程有沒有發生衝突嗎？”其實這個我們後來確實做了，解決方法是給我們的 K8s 加了 20 多個 Admission Hook。

第三，也是阿里巴巴上雲之後我們團隊特別痛的一個點。

我們需要處理的**應用的交付場景，除了公有云以外，還會有專有云、混合雲、IoT 等各種複雜的環境。各種各樣的雲服務在這種複雜場景下，連 API 都是不統一的**，這個時候我們就需要專門的交付團隊來進行彌補，一個一個的去對接、去交付應用。對他們來說這是一件非常痛苦的事情：“不是說好的 Docker 化了之後就能‘一次打包、隨處執行’了嗎？”說白了，K8s 現在並沒有一個統一的、平臺無關的應用描述能力。

## 阿里巴巴的解決辦法

在 2019 年，我們團隊開始思考如何透過技術手段解決上述應用管理與交付相關的問題，到現在已經取得了一定的成果。

不過，在講解阿里巴巴如何解決上述問題的方案之前，有必要先介紹一下我們推進所有這些方案的理論基礎。在這裡，我們主要遵循的是 CNCF 倡導的“[應用交付分層模型](https://docs.google.com/document/d/1gMhRz4vEwiHa3uD8DqFKHGTSxrVJNgkLG2WZWvi9lXo/edit#bookmark=id.qv45kp7nb29b)”，如下圖所示：

![](http://img.blog.itpub.net/blog/2019/11/23/53f671ddc7373c14.png?x-oss-process=style/bb)

**這個模型的基礎假設是：Kubernetes 本身並不提供完整的應用管理體系。**換句話說，基於 K8s 的應用管理體系，**不是一個開箱即用的功能**，而是需要基礎設施團隊基於雲原生社群和生態自己構建出來的。這裡面就需要引入很多開源專案或者能力。

而上面這個模型的一個重要作用，就是能夠把這些專案和能力以及它們的協作關係，非常清晰地分類和表達出來。

- 比如 Helm 就是位於整個應用管理體系的最上面，也就是第 1 層，還有 Kustomize 等各種 YAML 管理工具，CNAB 等打包工具，它們都對應在第 1.5 層；

- 然後有 Tekton、Flagger 、Kepton 等應用交付專案，包括髮布部署的流程，配置管理等，目前比較流行的是基於 GitOps 的管理，透過 git 作為“the source of truth”，一切都面向終態、透明化的管理，也方便對接，對應在第 2 層；

- 而 Operator 以及 K8s 的各種工作負載元件（Deployment、StatefulSet 等），具體來說就像某個例項掛了這些元件自動拉起來一個彌補上原來所需要三個的例項數，包括一些自愈、擴縮容等能力，對應在第 3 層；

- 最後一層則是平臺層，包括了所有底層的核心功能，負責對工作負載的容器進行管理、封裝基礎設施能力、對各種不同的工作負載對接底層基礎設施提供 API 等。

這些層次之間，透過相互之間的緊密協作，共同構建出一套高效、簡潔的應用管理與交付體系。在這些層次當中，目前阿里巴巴在今年 KubeCon 時已經宣佈開源了第三層的 [OpenKruise ](https://github.com/openkruise/kruise/)專案。最近，我們則正在聯合微軟等更廣泛的生態，和整個社群一起推進第一層“應用定義”相關的工作。

## 應用定義到底該怎麼做？

其實，關於應用定義，無論是開源社群還是在阿里巴巴內部，都已經做了不少嘗試，比如一開始我提到 Docker 解決了單機應用交付，它就透過 Docker 映象把單機應用定義的很好。

圍繞 Kubernetes 我們也試過使用 [Helm](https://helm.sh/) 以及 [Application CRD](https://github.com/kubernetes-sigs/application) 來定義應用。但是現在的雲原生應用，往往會依賴雲上的資源，像資料庫會依賴 RDS、訪問會依賴 SLB，Helm 和 Application CRD 只是單純地將 K8s 的 API 組合在一起，無法描述我們對雲上面資源的依賴，當我們用 CRD 來描述雲上資源依賴的時候，它其實是 freestyle 的，沒有一個很好的規範和約束，無論是使用者、開發、運維還是平臺資源提供方都沒有一個共識，自然也就無法協作和複用。

另一方面，它們既然是簡單的對 K8s API 的組合，那麼 K8s API 本身“**不面向應用研發和運維設計**”的問題就依然存在，這並不符合我們所希望的“應用定義”應該走的方向。此外，像 [Application CRD](https://github.com/kubernetes-sigs/application)，它雖然是 K8s 社群的專案，但是卻明顯缺乏社群活躍度，大多數修改都停留在一年前。

試了一圈，我們發現“應用定義”這個東西，在整個雲原生社群裡其實是缺失的。這也是為什麼阿里巴巴內部有很多團隊開始嘗試設計了自己的“定義應用”。簡單地說，這個設計其實就是把應用本身的映象、啟動引數、依賴的雲資源等等全部描述起來，分門別類的進行放置，並透過一個模板，最終渲染出一個配置檔案，檔案裡有上千個欄位，完整描述了一個應用定義的所有內容。這個配置檔案大概長下面這個樣子：

![](http://img.blog.itpub.net/blog/2019/11/23/e49dc5084c9190de.png?x-oss-process=style/bb)

除了基本的 Deployment 描述欄位，這種 in-house 應用定義往往還會包含雲上資源的宣告，比如使用哪種 ECS 套餐、如何續費、使用的是哪種磁碟和規格等等一系列額外的描述。這些資源的定義是一大塊，並且上面的例子裡我們已經儘量精簡了；另一大塊就是運維能力的描述，比如自動擴縮容、流量切換、灰度、監控等，涉及到一系列的規則。

然而，你也不難看到，這種定義方式最終所有的配置還是會全部堆疊到一個檔案裡，這跟 K8s API  all-in-one 的問題是一樣的，甚至還更嚴重了。而且，這些應用定義最終也都成為了黑盒，除了對應專案本身可以使用，其他系統基本無法複用，自然就更無法使得多方協作複用了。

吸取了這些教訓以後，我們團隊決定從另一個方向開始設計一個新的應用定義。

具體來說，相比於其他“應用定義”給 K8s 做加法、做整合的思路，**我們認為，真正良好的應用定義，應該給 K8s API 做“減法”。更準確的說，是我們應該透過“做減法”，把開發者真正關心的 API 給暴露出來，把運維、平臺關心的 API 給封裝起來。**

也就是說，既然 K8s API 為了方便基礎設施工程師，已經選擇把各方的關注點混在了一起。那麼，當基礎設施工程師想要基於 K8s 來服務更上層應用開發和運維人員時，其實應該考慮把這些關注點重新梳理出來，讓應用管理的各個參與方重新拿到屬於自己的 API 子集。

所以，我們開始在 K8s API 的基礎上增加了一層很薄的抽象，從而把原始的 K8s API 按照現實中的協作邏輯進行合理的拆分和分類，然後分別暴露給研發和運維去使用。這裡的原則是：研發拿到的 API 一定是研發視角的、沒有任何基礎設施的概念在裡面；而運維拿到的 API，一定是對 K8s 能力的模組化、宣告式的描述。這樣，在理想情況下，運維（或者平臺）就能夠對這些來自雙方的 API 物件進行組合，比如：應用 A + Autoscaler X，應用 B + Ingress Y。這樣組合完成後的描述物件，其實就可以完整的來描述“應用”這個東西了。

## Open Application Model （OAM）

在同社群進行交流和驗證中，我們發現：上面的這個思路正好跟當時微軟 Brendan Burns （Kubernetes 專案創始人）和 Matt Butcher （Helm 專案創始人）團隊的思路不謀而合。所以我們雙方在面對面交流了幾次之後，很快就決定共建這個專案並把它開源出來，跟整個社群生態一起來推進這件非常具有意義的事情。

今年 10 月 17 號，阿里雲小邪和微軟雲 CTO Mark 共同對外宣佈了這個專案的開源，它的官方名字叫做[ Open Application Model（OAM）](https://oam.dev/)，同時我們還宣佈了 OAM 對應的 K8s 實現——[Rudr 專案](https://github.com/oam-dev/rudr)。

具體來說，在設計 OAM 的時候，我們希望這個應用定義應該解決傳統應用定義的三個問題：

- 第一，不能有執行時鎖定。一套應用定義，必須可以不加修改跑到不同執行環境當中，無論是不是基於 K8s，這是解決我們在應用交付時所遇到的問題的關鍵。這才是真正的“一次定義、隨處執行”；

- 第二，這個應用定義必須要區分使用角色，而不是繼續延續 K8s 的 all-in-one API。 我們已經深刻了解到，我們所服務的應用開發人員，實際上很難、也不想關心運維以及 K8s 底層的各種概念，我們不應該讓他們原本已經很苦逼的日子變得更糟；

- 最後一個，這個應用定義必須不是在一個 YAML 裡描述所有東西。一旦一個應用定義裡把所有資訊全部耦合在一起，就會造成應用描述和運維描述被雜糅在一起，從而導致這個定義的複雜度成倍提升，也會讓這個定義完全無法複用。我們希望這些不同領域的描述能夠分開，然後平臺可以自由地組合搭配。

在這個思路下，我們最後設計出來的應用定義主要分為三個大塊：

- 第一部分是應用元件的描述，包括應用元件怎麼執行和該元件所依賴的各種資源。這個部分是開發負責編寫的；

- 第二部分是運維能力的描述，比如應用怎麼 scale、怎麼訪問、怎麼升級等策略。這個部分是運維負責編寫的；

- 第三部分是把上述描述檔案組合在一起的一個配置檔案。比如：“ 一個應用有兩個元件，元件 A 需要運維能力 X 和能力 Y，元件 B 需要運維能力 X”。所以這個配置檔案，其實才是最終的“應用”。這個配置檔案，也是運維編寫，並且提交給平臺去執行的，當然，平臺也可以自動生成這個檔案。

下面我們透過例項來看下以上三個部分對應的 YAML 檔案到底長什麼樣子？它們究竟怎麼玩兒？

備註：如果你想跟我一樣實際操作體驗這個流程，你只需要在 K8s 叢集裡[裝上 Rudr 專案](https://github.com/oam-dev/rudr/blob/master/docs/setup/install.md)就可以實操了。

### 第一部分：Component

![](http://img.blog.itpub.net/blog/2019/11/23/fd8ecb7dd0bb3b56.png?x-oss-process=style/bb)

首先我們可以看到，Component 定義的是開發關心的事情，沒有任何運維相關的概念。

它的 Spec 主要分為兩大塊：

第一個引數塊是應用描述，包括 WorkloadType 欄位，這個欄位就是表達應用使用什麼 Workload 執行，在我們設計裡有六種預設 Workload，分別是 Server、Worker、Job 以及他們對應的單例模式，Workload 也可以擴充套件。Server 代表這是一個可以自動伸縮的，並且有一個埠可以訪問的模式。接下來就是容器的映象、啟動引數之類的，這部分包含完整的 OCI spec。

第二塊是 parameters 如何執行可擴充套件的引數，如環境變數和埠號。這一塊引數的特點是：它們雖然是開發定義的，但是都允許運維後續覆蓋。這裡的關鍵點是，關注點分離並不等於完全割裂。所以，我們設計了 parameters 列表，其實就是希望開發能告訴運維，哪些引數後續可以被運維人員覆蓋掉。這樣的話就很好地聯動起來了，開發人員可以向運維人員提出訴求，比如運維應該使用哪些引數、引數代表什麼意思。

像這樣一個 Component 可以直接透過 kubectl 安裝到 K8s 中。

![](http://img.blog.itpub.net/blog/2019/11/23/1988ab776a57a9ed.png?x-oss-process=style/bb)

然後我們可以透過 kubectl 工具檢視到已經安裝好的元件有哪些：

![](http://img.blog.itpub.net/blog/2019/11/23/dc6a270799bf1b2b.png?x-oss-process=style/bb)

所以說，我們當前的 K8s 叢集，支援兩種“應用元件”。需要指出的是，除了我們內建支援的元件之外，開發自己可以自由定義各種各樣的元件然後提交給我們。Component Spec 裡的 Workload Type 是可以隨意擴充套件的，就跟 K8s 的 CRD 機制一樣。

### 第二部分： Trait

說完了開發能用的 API，我們再來看運維用的 API 長什麼樣。

在設計應用的運維能力定義的過程中，我們重點關注的是運維能力怎麼發現和管理的問題。

為此，我們設計了一個叫做 Trait 的概念。所謂 Trait，也就是應用的“特徵”，其實就是一種運維能力的宣告式描述。我們能透過命令列工具發現一個系統裡支援哪些 Traits（運維能力）。

![](http://img.blog.itpub.net/blog/2019/11/23/33ebda1fbaabde2f.png?x-oss-process=style/bb)

這時候，運維要檢視具體的運維能力該怎麼使用，是非常簡單的：

![](http://img.blog.itpub.net/blog/2019/11/23/982c8a1348c8c2cb.png?x-oss-process=style/bb)

可以看到，他可以在 Trait 定義裡清晰的看到這個運維能力可以作用於哪種型別的 Workload，包括能填哪些引數？哪些必填？哪些選填？引數的作用描述是什麼？ 你也可以發現，OAM 體系裡面，Component 和 Trait 這些 API 都是 Schema，所以它們是整個物件的欄位全集，也是瞭解這個物件描述的能力“到底能幹嗎？”的最佳途徑（反正基礎設施團隊的文件寫的也不咋地）。

上面這些 Trait 也都是用過 kubectl apply 就可以安裝到叢集當中的。

既然 Component 和 Trait 都是 Schema，那麼它們怎麼例項化成應用呢？

### 第三部分：Application Configuration

在 OAM 體系中，Application Configuration 是運維人員（或者系統本身也可以）執行應用部署等動作的操作物件。在 Application Configuration 裡，運維人員可以將 Trait 繫結到 Component 上執行。

在 Application Configuration YAML 裡面，運維可以把 Component 和 Trait 組裝起來，從而得到一個可以部署的“應用”：

![](http://img.blog.itpub.net/blog/2019/11/23/557ab3634382813c.png?x-oss-process=style/bb)

在這裡我們可以看到，運維例項化的應用裡面包含了一個叫 hellowworld-python-v1 的 Component，它有兩個引數：一個是環境變數 target，一個是port。需要注意的是，這兩個引數是運維人員覆蓋了原先 Component yaml 中開發定義的兩個可覆蓋變數。

同時，這個 Component 繫結了 2 個運維能力：一個是水平擴容，一個是 Ingress 域名訪問。

運維人員透過 kubectl 即可把這樣一個應用部署起來：

![](http://img.blog.itpub.net/blog/2019/11/23/c998a5f712744ef0.png?x-oss-process=style/bb)

這時候在 K8s 裡面，你就可以看到 OAM 外掛會自動為你建立出對應的 Deployment。

![](http://img.blog.itpub.net/blog/2019/11/23/461b4e7f2e4334f7.png?x-oss-process=style/bb)

同時，這個應用需要的 Ingress 也被自動建立起來了：

![](http://img.blog.itpub.net/blog/2019/11/23/a74fbf73494f0088.png?x-oss-process=style/bb)

這裡其實是前面提到的 Rudr 外掛在起作用，在拿到 OAM 的 Application Configuration 檔案以後，識別出其中的 Component 和 Trait，將其對映到 K8s 上的資源並拉起，K8s 資源相應的生命週期都隨著 OAM 的配置去管理。當然，由於 OAM 定義是平臺無關的，所以除了 K8s 本身的資源，Rudr 外掛的實現中也會加入外部資源的拉起。

### OAM YAML 檔案 =  一個自包含的軟體安裝包

最終我們可以透過像樂高積木一樣組裝複用 OAM 的不同模組，例項化出一個 OAM 的應用出來。更重要的是，這個 OAM 應用描述檔案是完全自包含的，也就是說透過 OAM YAML，作為軟體分發商，我們就可以完整地跟蹤到一個軟體執行所需要的所有資源和依賴。

![](http://img.blog.itpub.net/blog/2019/11/23/68bdd712638d2620.png?x-oss-process=style/bb)

這就使得現在對於一個應用，大家只需要一份 OAM 的配置檔案，就可以快速、在不同執行環境上把應用隨時執行起來，把這種自包含的應用描述檔案完整地交付到任何一個執行環境中。

這不僅讓我們前面提到的軟體交付難題得到了很好的解決，也讓更多非 K8s 平臺比如 IoT、遊戲分發、混合環境軟體交付等場景，能享受到雲原生應用管理的暢快。

## 最後
OAM 是一個完全屬於社群的應用定義模型，我們非常希望大家都能參與進來。

![](http://img.blog.itpub.net/blog/2019/11/23/187901aa94037321.png?x-oss-process=style/bb)

**（****釘釘掃碼加入交流群****）**

- 一方面，如果你有任何場景感覺 OAM 無法滿足的，歡迎你在社群提出 issue 來描述你的案例；

- 另一方面，OAM 模型也正在積極的同各個雲廠商、開源專案進行對接。

我們期待能與大家一起共建這個全新的應用管理生態。

## Q & A
**Q1**：OAM spec 中目前還沒有看到屬於 Infra Operator 的管理物件（補充：Component 是面向 App Developer，Traits 和 AppConfiguration 面向 App Operator，哪個物件是面向 Infra Operator 的？）
**A1**：OAM 本身就是基礎設施運維手裡的武器，包括 Kubernetes、Terraform 等一系列平臺層的開源專案，基礎設施運維可以透過這些開源專案構建 OAM 的實現（如 Rudr 基於 Kubernetes）。所以 OAM 的實現層就是基礎設施運維提供的，他們不需要額外的物件來使用 OAM。

**Q2**：OAM Controller和 admission controller 的分工標準是什麼？
**A2**：OAM 專案中的 admission controller 用於轉換和檢驗 spec，完全等價於 K8s 中 admission controller。目前實現的功能包括轉換 [fromVariable(VAR)] 這種 spec 中的函式，檢驗 AppConfig、Component、Trait、Scope 等 CR 是否符合規範，是否合法等。OAM Controller，即目前的開源專案 Rudr，就是整個 OAM 的實現層，它負責解釋 OAM 的 spec 並轉換為真實執行的資源，這裡的資源可以是 K8s 原有的一些，也可以是像阿里雲上的 RDS 這類雲資源。目前 Rudr 專案是 Rust 語言寫的，考慮到 K8s 生態大多數都是用 Go 語言寫的，我們後續也會開源一個 Go 語言編寫的 OAM-Framework，用於快速實現像 Rrudr 這樣的 OAM 實現層。

**Q3**：計劃啥時候開源 Go 的 OAM-Framework 呀？
**A3**：我們需要一點時間進一步打磨 OAM-Framework ，讓它適配大家的場景。但是應該很快就會跟大家見面。

**Q4**：阿里是如何降低 K8s 的複雜度來滿足運維和研發一些共性訴求的？在 K8s 中的使用者 user 角色可能是開發也可能是運維。
**A4**：目前我們遇到的大多數場景都能區分哪些是運維要關心的，哪些是研發要關心的。OAM 降低 K8s 複雜度的主要方法就是關注點分離，給 K8s 的 API 做減法，儘量讓某一方可以少關注一些內容。如果你有這樣一個無法分割的場景，其實我們也很感興趣，歡迎把 case 提出來一起探討。另一方面，我們並不是遮蔽掉 K8s，OAM Spec 預留了充足的擴充套件性，完全可以把K8s原有的能力提供給使用者。

**Q5**：我認為 OAM 是基於 K8s 針對於不同應用上的抽象層，現在我們有很多應用都是用 Helm 包包裝好的，如果切換成 OAM 的話，我們需要注意哪些地方呢？
**A5**：其實我們上半年一直在推廣 Helm 在國內的使用，包括提供了阿里巴巴的 Helm 映象站（https://developer.aliyun.com/hub）等，所以 OAM 跟 Helm 也是相輔相成的。簡單的說，OAM 其實就是 Helm 包裡面 template 資料夾裡面的內容。Helm 是 OAM 做引數渲染（template）和打包（chart）的工具。如果切換到 OAM，Helm 的使用方式不需要變，裡面的 spec 換成 OAM 的 spec 即可。

**Q6**：請問，Rudr 用起來了嗎，效果如何。Rudr 的架構有沒更豐富的資料？
**A6**：Rudr 一直是可以用的，大家要是用不起來可以提 issue，想要什麼方面的資料或者疑問也可以提 issue，我們也在完善文件。目前相關的材料都在這裡：
https://github.com/oam-dev/rudr/tree/master/docs

**Q7：**我們一直在用 Helm 打包我們的應用，去做 gitops ，一個通用的 chart 對應不同的 values.yaml 做到了複用。聽了分享，很期待 OAM，當然還有 Openkruise。<br>**A7：**Openkruise 是開源的哈，大家可以關注 https://github.com/openkruise/kruise 我們也一直在迭代。

**Q8**：OAM 有哪些公司在用？實際體驗反饋如何？
**A8**：OAM 剛剛釋出一個月左右，具體有哪些公司已經在使用我們還沒有來得及統計。阿里巴巴和微軟內部都已經在使用，並且都有對外的產品使用 OAM。就我們接觸到的使用者來說，無論是社群的使用者還是阿里巴巴內部，都對 OAM 的關注點分離等理念非常認同，也都在積極落地。

---

**社群分享文章整理**

**Vol 1** : [當 K8s 叢集達到萬級規模，阿里巴巴如何解決系統各元件效能問題？](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247486535&idx=1&sn=f8093f56481c504087f26abd6b018402&chksm=fae50788cd928e9ef535511668479330452fb8555065094ff8a16c9650915bba29365ffb697d&scene=21#wechat_redirect)

**Vol 2** : [超大規模商用 K8s 場景下，阿里巴巴如何動態解決容器資源的按需分配問題？](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247486925&idx=1&sn=6d9f32e385a299890a1a1b86a8e2ddae&chksm=fae50602cd928f142bdbdba77389897bbe51c5decea630f0e6feb82bc2c11d2ac014459d3c68&scene=21#wechat_redirect)

**Vol 3** : [備戰雙 11！](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247487170&idx=1&sn=f90c539fa3a1b5aa071ae0ed67d0974a&chksm=fae5050dcd928c1b898a9c7edd6b1685eb588eadc786bad49db8d697077b43bed5cc31cd59af&scene=21#wechat_redirect)[螞蟻金服萬級規模 K8s 叢集管理系統如何設計？](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247487170&idx=1&sn=f90c539fa3a1b5aa071ae0ed67d0974a&chksm=fae5050dcd928c1b898a9c7edd6b1685eb588eadc786bad49db8d697077b43bed5cc31cd59af&scene=21#wechat_redirect)

**Vol 4 **: [帶你上手一款下載超 10 萬次的 IEDA 外掛](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247487491&idx=1&sn=60fc38f561a7f96264b8aeaa95b92d5f&chksm=fae51bcccd9292da66cc36bb63fba2b08b0665274825a496cec87becbdfece5ae024a08281c1&scene=21#wechat_redirect)

>“ 阿里巴巴雲原生微信公眾號（ID：Alicloudnative）關注微服務、Serverless、容器、Service Mesh等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術公眾號。”

給 K8s API “做減法”：阿里巴巴雲原生應用管理的挑戰和實踐

相關文章