给 K8s API “做减法”：阿里巴巴云原生应用管理的挑战和实践
作者 | 孫健波（天元）? 阿里巴巴技術(shù)專家
本文整理自 11 月 21 日社群分享，每月 2 場高質(zhì)量分享，點擊加入社群。
早在 2011 年，阿里巴巴內(nèi)部便開始了應(yīng)用容器化，當(dāng)時最開始是基于 LXC 技術(shù)構(gòu)建容器，然后逐漸切換到 Docker，自研了大規(guī)模編排調(diào)度系統(tǒng)。到了 2018 年，我們團隊依托 K8s 體系開始推進“輕量級容器化”，同時投入了工程力量跟開源社區(qū)一起解決了諸多規(guī)模與性能問題，從而逐步將過去“類虛擬機”的運維鏈路和阿里巴巴整體應(yīng)用基礎(chǔ)設(shè)施架構(gòu)升級到了云原生技術(shù)棧。
到了 2019 年，Kubernetes 基礎(chǔ)設(shè)施底盤在阿里巴巴經(jīng)濟體中已經(jīng)覆蓋了阿里巴巴方方面面的業(yè)務(wù)，規(guī)模化的接入了包括核心電商、物流、金融、外賣、搜索、計算、AI 等諸多頭部互聯(lián)網(wǎng)場景。這套技術(shù)底盤，也逐步成為了阿里巴巴支撐 618、雙11 等互聯(lián)網(wǎng)級大促的主力軍之一。
目前，阿里巴巴與螞蟻金服內(nèi)部運行了數(shù)十個超大規(guī)模的 K8s 集群，其中最大的集群約 1 萬個機器節(jié)點，而其實這還不是能力上限。每個集群都會服務(wù)上萬個應(yīng)用。在阿里云 Kubernetes 服務(wù)（ACK）上，我們還維護了上萬個用戶的 K8s 集群，這個規(guī)模和其中的技術(shù)挑戰(zhàn)在全世界也是首屈一指的。
我們的 Kubernetes 面臨的新挑戰(zhàn)
在規(guī)模和性能等基礎(chǔ)設(shè)施領(lǐng)域問題逐步解決的同時，規(guī)模化鋪開 Kubernetes 的過程中，我們逐步發(fā)現(xiàn)這套體系里其實還有很多意想不到的挑戰(zhàn)。這也是今天分享的主題。
第一個是 K8s 的 API 里其實并沒有“應(yīng)用”的概念
而且，Kubernetes API 的設(shè)計把研發(fā)、運維還有基礎(chǔ)設(shè)施關(guān)心的事情全都糅雜在一起了。這導(dǎo)致研發(fā)覺得 K8s 太復(fù)雜，運維覺得 K8s 的能力非常凌亂、零散，不好管理，只有基礎(chǔ)設(shè)施團隊（也就是我們團隊）覺得 Kubernetes 比較好用。但是基礎(chǔ)設(shè)施團隊也很難跟研發(fā)和運維解釋清楚 Kubernetes 的價值到底是什么。
我們來看個實際的例子。
就拿上圖中的 replica 為 3 來說，開發(fā)人員怎么知道實例數(shù)應(yīng)該配幾個呢？如果運維想要改replica，敢不敢改？能不能改？如果 replica 還能理解的話，那像 shareProcessNamespace 這種字段真是靈魂拷問了。 開發(fā)人員僅從字面意思知道這個可能跟容器進程共享有關(guān)，那么配置了這個應(yīng)用會有什么影響呢？會不會有安全問題？
在阿里巴巴內(nèi)部，很多 PaaS 平臺只允許開發(fā)填 Deployment 的極個別字段。為什么允許填的字段這么少？是平臺能力不夠強嗎？其實不是的，本質(zhì)原因在于業(yè)務(wù)開發(fā)根本不想理解這眾多的字段。
所以這個 PaaS 平臺只允許用戶填個別字段，其實反倒是幫助業(yè)務(wù)開發(fā)人員避免了這些靈魂拷問。但反過來想，屏蔽掉大量字段真的就解決問題了嗎？這種情況下，整個組織的基礎(chǔ)設(shè)施能力還如何演進？應(yīng)用開發(fā)和應(yīng)用運維人員的訴求又該怎么傳遞給基礎(chǔ)設(shè)施呢？
實際上，歸根到底，Kubernetes 是一個 Platform for Platform 項目，它的設(shè)計是給基礎(chǔ)設(shè)施工程師用來構(gòu)建其他平臺用的（比如 PaaS 或者 Serverless），而不是直面研發(fā)和運維同學(xué)的。從這個角度來看，Kubernetes 的 API，其實可以類比于 Linux Kernel 的 System Call，這跟研發(fā)和運維真正要用的東西（Userspace 工具）完全不是一個層次上的。你總不能讓本來寫 Java Web 的同學(xué)每天直接調(diào)用著 Linux Kernel System Call，還給你點贊吧？
第二， K8s 實在是太靈活了，插件太多了，各種人員開發(fā)的 Controller 和 Operator 也非常多。
這種靈活性，讓我們團隊開發(fā)各種能力很容易，但也使得對于應(yīng)用運維來說， K8s 的這些能力管理變得非常困難。比如一個環(huán)境里的不同運維能力，實際上有可能是沖突的。
我們來看一個例子，基礎(chǔ)設(shè)施團隊最近開發(fā)上線了一個新的插件，叫做 CronHPA，一個具體的 Spec 如下所示。
作為基礎(chǔ)設(shè)施團隊，我們覺得這種 K8s 插件很簡單， CRD 也很容易理解。就像這個 CronHPA 的功能，從早上六點開始到下午七點鐘這個實例最少有 20 個、最多有 25 個，到第二天早上六點鐘最少 1 個、最多有 9 個，在每個階段會根據(jù) CPU 這個指標(biāo)衡量調(diào)整實例數(shù)。
然而，就在我們美滋滋的上線這個插件后不久，應(yīng)用運維同學(xué)就開始跟我們抱怨了：
第三，也是阿里巴巴上云之后我們團隊特別痛的一個點。
我們需要處理的應(yīng)用的交付場景，除了公有云以外，還會有專有云、混合云、IoT 等各種復(fù)雜的環(huán)境。各種各樣的云服務(wù)在這種復(fù)雜場景下，連 API 都是不統(tǒng)一的，這個時候我們就需要專門的交付團隊來進行彌補，一個一個的去對接、去交付應(yīng)用。對他們來說這是一件非常痛苦的事情：“不是說好的 Docker 化了之后就能‘一次打包、隨處運行’了嗎？”說白了，K8s 現(xiàn)在并沒有一個統(tǒng)一的、平臺無關(guān)的應(yīng)用描述能力。
阿里巴巴的解決辦法
在 2019 年，我們團隊開始思考如何通過技術(shù)手段解決上述應(yīng)用管理與交付相關(guān)的問題，到現(xiàn)在已經(jīng)取得了一定的成果。
不過，在講解阿里巴巴如何解決上述問題的方案之前，有必要先介紹一下我們推進所有這些方案的理論基礎(chǔ)。在這里，我們主要遵循的是?CNCF 倡導(dǎo)的“應(yīng)用交付分層模型”，如下圖所示：
這個模型的基礎(chǔ)假設(shè)是：Kubernetes 本身并不提供完整的應(yīng)用管理體系。換句話說，基于 K8s 的應(yīng)用管理體系，不是一個開箱即用的功能，而是需要基礎(chǔ)設(shè)施團隊基于云原生社區(qū)和生態(tài)自己構(gòu)建出來的。這里面就需要引入很多開源項目或者能力。
而上面這個模型的一個重要作用，就是能夠把這些項目和能力以及它們的協(xié)作關(guān)系，非常清晰地分類和表達出來。
- 比如 Helm 就是位于整個應(yīng)用管理體系的最上面，也就是第 1 層，還有 Kustomize 等各種 YAML 管理工具，CNAB 等打包工具，它們都對應(yīng)在第 1.5 層；
- 然后有 Tekton、Flagger 、Kepton 等應(yīng)用交付項目，包括發(fā)布部署的流程，配置管理等，目前比較流行的是基于 GitOps 的管理，通過 git 作為“the source of truth”，一切都面向終態(tài)、透明化的管理，也方便對接，對應(yīng)在第 2 層；
- 而 Operator 以及 K8s 的各種工作負載組件（Deployment、StatefulSet?等），具體來說就像某個實例掛了這些組件自動拉起來一個彌補上原來所需要三個的實例數(shù)，包括一些自愈、擴縮容等能力，對應(yīng)在第 3 層；
- 最后一層則是平臺層，包括了所有底層的核心功能，負責(zé)對工作負載的容器進行管理、封裝基礎(chǔ)設(shè)施能力、對各種不同的工作負載對接底層基礎(chǔ)設(shè)施提供 API 等。
這些層次之間，通過相互之間的緊密協(xié)作，共同構(gòu)建出一套高效、簡潔的應(yīng)用管理與交付體系。在這些層次當(dāng)中，目前阿里巴巴在今年 KubeCon 時已經(jīng)宣布開源了第三層的 OpenKruise 項目。最近，我們則正在聯(lián)合微軟等更廣泛的生態(tài)，和整個社區(qū)一起推進第一層“應(yīng)用定義”相關(guān)的工作。
應(yīng)用定義到底該怎么做？
其實，關(guān)于應(yīng)用定義，無論是開源社區(qū)還是在阿里巴巴內(nèi)部，都已經(jīng)做了不少嘗試，比如一開始我提到 Docker 解決了單機應(yīng)用交付，它就通過 Docker 鏡像把單機應(yīng)用定義的很好。
圍繞 Kubernetes 我們也試過使用 Helm 以及 Application CRD 來定義應(yīng)用。但是現(xiàn)在的云原生應(yīng)用，往往會依賴云上的資源，像數(shù)據(jù)庫會依賴 RDS、訪問會依賴 SLB，Helm 和 Application CRD 只是單純地將 K8s 的 API 組合在一起，無法描述我們對云上面資源的依賴，當(dāng)我們用 CRD 來描述云上資源依賴的時候，它其實是 freestyle 的，沒有一個很好的規(guī)范和約束，無論是用戶、開發(fā)、運維還是平臺資源提供方都沒有一個共識，自然也就無法協(xié)作和復(fù)用。
另一方面，它們既然是簡單的對 K8s API 的組合，那么 K8s API 本身“不面向應(yīng)用研發(fā)和運維設(shè)計”的問題就依然存在，這并不符合我們所希望的“應(yīng)用定義”應(yīng)該走的方向。此外，像 Application CRD，它雖然是 K8s 社區(qū)的項目，但是卻明顯缺乏社區(qū)活躍度，大多數(shù)修改都停留在一年前。
試了一圈，我們發(fā)現(xiàn)“應(yīng)用定義”這個東西，在整個云原生社區(qū)里其實是缺失的。這也是為什么阿里巴巴內(nèi)部有很多團隊開始嘗試設(shè)計了自己的“定義應(yīng)用”。簡單地說，這個設(shè)計其實就是把應(yīng)用本身的鏡像、啟動參數(shù)、依賴的云資源等等全部描述起來，分門別類的進行放置，并通過一個模板，最終渲染出一個配置文件，文件里有上千個字段，完整描述了一個應(yīng)用定義的所有內(nèi)容。這個配置文件大概長下面這個樣子：
除了基本的 Deployment?描述字段，這種 in-house 應(yīng)用定義往往還會包含云上資源的聲明，比如使用哪種 ECS 套餐、如何續(xù)費、使用的是哪種磁盤和規(guī)格等等一系列額外的描述。這些資源的定義是一大塊，并且上面的例子里我們已經(jīng)盡量精簡了；另一大塊就是運維能力的描述，比如自動擴縮容、流量切換、灰度、監(jiān)控等，涉及到一系列的規(guī)則。
然而，你也不難看到，這種定義方式最終所有的配置還是會全部堆疊到一個文件里，這跟 K8s API all-in-one 的問題是一樣的，甚至還更嚴重了。而且，這些應(yīng)用定義最終也都成為了黑盒，除了對應(yīng)項目本身可以使用，其他系統(tǒng)基本無法復(fù)用，自然就更無法使得多方協(xié)作復(fù)用了。
吸取了這些教訓(xùn)以后，我們團隊決定從另一個方向開始設(shè)計一個新的應(yīng)用定義。
具體來說，相比于其他“應(yīng)用定義”給 K8s 做加法、做整合的思路，我們認為，真正良好的應(yīng)用定義，應(yīng)該給 K8s API 做“減法”。更準(zhǔn)確的說，是我們應(yīng)該通過“做減法”，把開發(fā)者真正關(guān)心的 API 給暴露出來，把運維、平臺關(guān)心的 API 給封裝起來。
也就是說，既然 K8s API 為了方便基礎(chǔ)設(shè)施工程師，已經(jīng)選擇把各方的關(guān)注點混在了一起。那么，當(dāng)基礎(chǔ)設(shè)施工程師想要基于 K8s 來服務(wù)更上層應(yīng)用開發(fā)和運維人員時，其實應(yīng)該考慮把這些關(guān)注點重新梳理出來，讓應(yīng)用管理的各個參與方重新拿到屬于自己的 API 子集。
所以，我們開始在 K8s API 的基礎(chǔ)上增加了一層很薄的抽象，從而把原始的 K8s API 按照現(xiàn)實中的協(xié)作邏輯進行合理的拆分和分類，然后分別暴露給研發(fā)和運維去使用。這里的原則是：研發(fā)拿到的 API 一定是研發(fā)視角的、沒有任何基礎(chǔ)設(shè)施的概念在里面；而運維拿到的 API，一定是對 K8s 能力的模塊化、聲明式的描述。這樣，在理想情況下，運維（或者平臺）就能夠?qū)@些來自雙方的 API 對象進行組合，比如：應(yīng)用 A Autoscaler X，應(yīng)用 B Ingress Y。這樣組合完成后的描述對象，其實就可以完整的來描述“應(yīng)用”這個東西了。
Open Application Model （OAM）
在同社區(qū)進行交流和驗證中，我們發(fā)現(xiàn)：上面的這個思路正好跟當(dāng)時微軟 Brendan Burns （Kubernetes 項目創(chuàng)始人）和 Matt Butcher （Helm 項目創(chuàng)始人）團隊的思路不謀而合。所以我們雙方在面對面交流了幾次之后，很快就決定共建這個項目并把它開源出來，跟整個社區(qū)生態(tài)一起來推進這件非常具有意義的事情。
今年 10 月 17 號，阿里云小邪和微軟云 CTO Mark 共同對外宣布了這個項目的開源，它的官方名字叫做 Open Application Model（OAM），同時我們還宣布了 OAM 對應(yīng)的 K8s 實現(xiàn)——Rudr 項目。
具體來說，在設(shè)計 OAM 的時候，我們希望這個應(yīng)用定義應(yīng)該解決傳統(tǒng)應(yīng)用定義的三個問題：
- 第一，不能有運行時鎖定。一套應(yīng)用定義，必須可以不加修改跑到不同運行環(huán)境當(dāng)中，無論是不是基于 K8s，這是解決我們在應(yīng)用交付時所遇到的問題的關(guān)鍵。這才是真正的“一次定義、隨處運行”；
- 第二，這個應(yīng)用定義必須要區(qū)分使用角色，而不是繼續(xù)延續(xù) K8s 的 all-in-one API。 我們已經(jīng)深刻了解到，我們所服務(wù)的應(yīng)用開發(fā)人員，實際上很難、也不想關(guān)心運維以及 K8s 底層的各種概念，我們不應(yīng)該讓他們原本已經(jīng)很苦逼的日子變得更糟；
- 最后一個，這個應(yīng)用定義必須不是在一個 YAML 里描述所有東西。一旦一個應(yīng)用定義里把所有信息全部耦合在一起，就會造成應(yīng)用描述和運維描述被雜糅在一起，從而導(dǎo)致這個定義的復(fù)雜度成倍提升，也會讓這個定義完全無法復(fù)用。我們希望這些不同領(lǐng)域的描述能夠分開，然后平臺可以自由地組合搭配。
在這個思路下，我們最后設(shè)計出來的應(yīng)用定義主要分為三個大塊：
- 第一部分是應(yīng)用組件的描述，包括應(yīng)用組件怎么運行和該組件所依賴的各種資源。這個部分是開發(fā)負責(zé)編寫的；
- 第二部分是運維能力的描述，比如應(yīng)用怎么 scale、怎么訪問、怎么升級等策略。這個部分是運維負責(zé)編寫的；
- 第三部分是把上述描述文件組合在一起的一個配置文件。比如：“ 一個應(yīng)用有兩個組件，組件 A 需要運維能力 X 和能力 Y，組件 B 需要運維能力 X”。所以這個配置文件，其實才是最終的“應(yīng)用”。這個配置文件，也是運維編寫，并且提交給平臺去運行的，當(dāng)然，平臺也可以自動生成這個文件。
下面我們通過實例來看下以上三個部分對應(yīng)的 YAML 文件到底長什么樣子？它們究竟怎么玩兒？
備注：如果你想跟我一樣實際操作體驗這個流程，你只需要在 K8s 集群里裝上 Rudr 項目就可以實操了。
第一部分：Component
首先我們可以看到，Component 定義的是開發(fā)關(guān)心的事情，沒有任何運維相關(guān)的概念。
它的 Spec 主要分為兩大塊：
第一個參數(shù)塊是應(yīng)用描述，包括 WorkloadType 字段，這個字段就是表達應(yīng)用使用什么 Workload 運行，在我們設(shè)計里有六種默認 Workload，分別是 Server、Worker、Job 以及他們對應(yīng)的單例模式，Workload 也可以擴展。Server 代表這是一個可以自動伸縮的，并且有一個端口可以訪問的模式。接下來就是容器的鏡像、啟動參數(shù)之類的，這部分包含完整的 OCI spec。
第二塊是 parameters 如何運行可擴展的參數(shù)，如環(huán)境變量和端口號。這一塊參數(shù)的特點是：它們雖然是開發(fā)定義的，但是都允許運維后續(xù)覆蓋。這里的關(guān)鍵點是，關(guān)注點分離并不等于完全割裂。所以，我們設(shè)計了 parameters 列表，其實就是希望開發(fā)能告訴運維，哪些參數(shù)后續(xù)可以被運維人員覆蓋掉。這樣的話就很好地聯(lián)動起來了，開發(fā)人員可以向運維人員提出訴求，比如運維應(yīng)該使用哪些參數(shù)、參數(shù)代表什么意思。
像這樣一個 Component 可以直接通過 kubectl 安裝到 K8s 中。
然后我們可以通過 kubectl 工具查看到已經(jīng)安裝好的組件有哪些：
所以說，我們當(dāng)前的 K8s 集群，支持兩種“應(yīng)用組件”。需要指出的是，除了我們內(nèi)置支持的組件之外，開發(fā)自己可以自由定義各種各樣的組件然后提交給我們。Component Spec 里的 Workload Type 是可以隨意擴展的，就跟 K8s 的 CRD 機制一樣。
第二部分： Trait
說完了開發(fā)能用的 API，我們再來看運維用的 API 長什么樣。
在設(shè)計應(yīng)用的運維能力定義的過程中，我們重點關(guān)注的是運維能力怎么發(fā)現(xiàn)和管理的問題。
為此，我們設(shè)計了一個叫做 Trait 的概念。所謂 Trait，也就是應(yīng)用的“特征”，其實就是一種運維能力的聲明式描述。我們能通過命令行工具發(fā)現(xiàn)一個系統(tǒng)里支持哪些 Traits（運維能力）。
這時候，運維要查看具體的運維能力該怎么使用，是非常簡單的：
可以看到，他可以在 Trait 定義里清晰的看到這個運維能力可以作用于哪種類型的 Workload，包括能填哪些參數(shù)？哪些必填？哪些選填？參數(shù)的作用描述是什么？ 你也可以發(fā)現(xiàn)，OAM 體系里面，Component 和 Trait 這些 API 都是 Schema，所以它們是整個對象的字段全集，也是了解這個對象描述的能力“到底能干嗎？”的最佳途徑（反正基礎(chǔ)設(shè)施團隊的文檔寫的也不咋地）。
上面這些 Trait 也都是用過 kubectl apply 就可以安裝到集群當(dāng)中的。
既然 Component 和 Trait 都是 Schema，那么它們怎么實例化成應(yīng)用呢？
第三部分：Application Configuration
在 OAM 體系中，Application Configuration 是運維人員（或者系統(tǒng)本身也可以）執(zhí)行應(yīng)用部署等動作的操作對象。在 Application Configuration 里，運維人員可以將 Trait 綁定到 Component 上執(zhí)行。
在 Application Configuration YAML 里面，運維可以把 Component 和 Trait 組裝起來，從而得到一個可以部署的“應(yīng)用”：
在這里我們可以看到，運維實例化的應(yīng)用里面包含了一個叫 hellowworld-python-v1 的 Component，它有兩個參數(shù)：一個是環(huán)境變量 target，一個是port。需要注意的是，這兩個參數(shù)是運維人員覆蓋了原先 Component yaml 中開發(fā)定義的兩個可覆蓋變量。
同時，這個 Component 綁定了 2 個運維能力：一個是水平擴容，一個是 Ingress 域名訪問。
運維人員通過 kubectl 即可把這樣一個應(yīng)用部署起來：
這時候在 K8s 里面，你就可以看到 OAM 插件會自動為你創(chuàng)建出對應(yīng)的 Deployment。
同時，這個應(yīng)用需要的 Ingress 也被自動創(chuàng)建起來了：
這里其實是前面提到的 Rudr 插件在起作用，在拿到 OAM 的 Application Configuration 文件以后，識別出其中的 Component 和 Trait，將其映射到 K8s 上的資源并拉起，K8s 資源相應(yīng)的生命周期都隨著 OAM 的配置去管理。當(dāng)然，由于 OAM 定義是平臺無關(guān)的，所以除了 K8s 本身的資源，Rudr 插件的實現(xiàn)中也會加入外部資源的拉起。
OAM YAML 文件 = 一個自包含的軟件安裝包
最終我們可以通過像樂高積木一樣組裝復(fù)用 OAM 的不同模塊，實例化出一個 OAM 的應(yīng)用出來。更重要的是，這個 OAM 應(yīng)用描述文件是完全自包含的，也就是說通過 OAM YAML，作為軟件分發(fā)商，我們就可以完整地跟蹤到一個軟件運行所需要的所有資源和依賴。
這就使得現(xiàn)在對于一個應(yīng)用，大家只需要一份 OAM 的配置文件，就可以快速、在不同運行環(huán)境上把應(yīng)用隨時運行起來，把這種自包含的應(yīng)用描述文件完整地交付到任何一個運行環(huán)境中。
這不僅讓我們前面提到的軟件交付難題得到了很好的解決，也讓更多非 K8s 平臺比如?IoT、游戲分發(fā)、混合環(huán)境軟件交付等場景，能享受到云原生應(yīng)用管理的暢快。
最后
OAM 是一個完全屬于社區(qū)的應(yīng)用定義模型，我們非常希望大家都能參與進來。
（釘釘掃碼加入交流群）
- 一方面，如果你有任何場景感覺 OAM 無法滿足的，歡迎你在社區(qū)提出 issue 來描述你的案例；
- 另一方面，OAM 模型也正在積極的同各個云廠商、開源項目進行對接。
我們期待能與大家一起共建這個全新的應(yīng)用管理生態(tài)。
Q & A
Q1：OAM?spec 中目前還沒有看到屬于 Infra Operator 的管理對象（補充：Component 是面向 App Developer，Traits 和 AppConfiguration 面向 App Operator，哪個對象是面向 Infra Operator 的？）A1：OAM 本身就是基礎(chǔ)設(shè)施運維手里的武器，包括 Kubernetes、Terraform 等一系列平臺層的開源項目，基礎(chǔ)設(shè)施運維可以通過這些開源項目構(gòu)建 OAM 的實現(xiàn)（如 Rudr 基于 Kubernetes）。所以 OAM 的實現(xiàn)層就是基礎(chǔ)設(shè)施運維提供的，他們不需要額外的對象來使用 OAM。
Q2：OAM Controller和 admission controller 的分工標(biāo)準(zhǔn)是什么？A2：OAM 項目中的 admission controller 用于轉(zhuǎn)換和檢驗 spec，完全等價于 K8s 中 admission controller。目前實現(xiàn)的功能包括轉(zhuǎn)換 [fromVariable(VAR)] 這種 spec 中的函數(shù)，檢驗 AppConfig、Component、Trait、Scope 等 CR 是否符合規(guī)范，是否合法等。OAM Controller，即目前的開源項目 Rudr，就是整個 OAM 的實現(xiàn)層，它負責(zé)解釋 OAM 的 spec 并轉(zhuǎn)換為真實運行的資源，這里的資源可以是 K8s 原有的一些，也可以是像阿里云上的 RDS 這類云資源。目前 Rudr 項目是 Rust 語言寫的，考慮到 K8s 生態(tài)大多數(shù)都是用 Go 語言寫的，我們后續(xù)也會開源一個 Go 語言編寫的 OAM-Framework，用于快速實現(xiàn)像 Rrudr 這樣的 OAM 實現(xiàn)層。
Q3：計劃啥時候開源 Go 的?OAM-Framework 呀？A3：我們需要一點時間進一步打磨 OAM-Framework ，讓它適配大家的場景。但是應(yīng)該很快就會跟大家見面。
Q4：阿里是如何降低 K8s 的復(fù)雜度來滿足運維和研發(fā)一些共性訴求的？在 K8s 中的用戶 user 角色可能是開發(fā)也可能是運維。A4：目前我們遇到的大多數(shù)場景都能區(qū)分哪些是運維要關(guān)心的，哪些是研發(fā)要關(guān)心的。OAM 降低 K8s 復(fù)雜度的主要方法就是關(guān)注點分離，給 K8s 的 API 做減法，盡量讓某一方可以少關(guān)注一些內(nèi)容。如果你有這樣一個無法分割的場景，其實我們也很感興趣，歡迎把 case 提出來一起探討。另一方面，我們并不是屏蔽掉 K8s，OAM Spec 預(yù)留了充足的擴展性，完全可以把K8s原有的能力提供給用戶。
Q5：我認為 OAM 是基于 K8s 針對于不同應(yīng)用上的抽象層，現(xiàn)在我們有很多應(yīng)用都是用 Helm 包包裝好的，如果切換成 OAM 的話，我們需要注意哪些地方呢？A5：其實我們上半年一直在推廣 Helm 在國內(nèi)的使用，包括提供了阿里巴巴的 Helm 鏡像站（https://developer.aliyun.com/hub）等，所以 OAM 跟 Helm 也是相輔相成的。簡單的說，OAM 其實就是 Helm 包里面 template 文件夾里面的內(nèi)容。Helm 是 OAM 做參數(shù)渲染（template）和打包（chart）的工具。如果切換到 OAM，Helm 的使用方式不需要變，里面的 spec 換成 OAM 的 spec 即可。
Q6：請問，Rudr 用起來了嗎，效果如何。Rudr 的架構(gòu)有沒更豐富的資料？A6：Rudr?一直是可以用的，大家要是用不起來可以提 issue，想要什么方面的資料或者疑問也可以提 issue，我們也在完善文檔。目前相關(guān)的材料都在這里：https://github.com/oam-dev/rudr/tree/master/docs
Q7：我們一直在用 Helm 打包我們的應(yīng)用，去做 gitops ，一個通用的 chart 對應(yīng)不同的 values.yaml 做到了復(fù)用。聽了分享，很期待 OAM，當(dāng)然還有 Openkruise。
A7：Openkruise 是開源的哈，大家可以關(guān)注?https://github.com/openkruise/kruise?我們也一直在迭代。
Q8：OAM?有哪些公司在用？實際體驗反饋如何？A8：OAM 剛剛發(fā)布一個月左右，具體有哪些公司已經(jīng)在使用我們還沒有來得及統(tǒng)計。阿里巴巴和微軟內(nèi)部都已經(jīng)在使用，并且都有對外的產(chǎn)品使用 OAM。就我們接觸到的用戶來說，無論是社區(qū)的用戶還是阿里巴巴內(nèi)部，都對 OAM 的關(guān)注點分離等理念非常認同，也都在積極落地。
社群分享文章整理
Vol 1?: 當(dāng) K8s 集群達到萬級規(guī)模，阿里巴巴如何解決系統(tǒng)各組件性能問題？
Vol 2?: 超大規(guī)模商用 K8s 場景下，阿里巴巴如何動態(tài)解決容器資源的按需分配問題？
Vol 3?: 備戰(zhàn)雙 11！螞蟻金服萬級規(guī)模 K8s 集群管理系統(tǒng)如何設(shè)計？
Vol 4?: 帶你上手一款下載超 10 萬次的?IEDA?插件
“ 阿里巴巴云原生微信公眾號（ID：Alicloudnative）關(guān)注微服務(wù)、Serverless、容器、Service Mesh等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢、云原生大規(guī)模的落地實踐，做最懂云原生開發(fā)者的技術(shù)公眾號。”
?
總結(jié)
以上是生活随笔為你收集整理的给 K8s API “做减法”：阿里巴巴云原生应用管理的挑战和实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Mirantis 收购 Docker E
- 下一篇： 从零开始入门 | Kubernetes