作者 | 孫健波（天元）? 阿里巴巴技術(shù)專家

成都創(chuàng)新互聯(lián)公司于2013年創(chuàng)立，先為巫山等服務(wù)建站，巫山等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為巫山企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問(wèn)題。

本文整理自 11 月 21 日社群分享，每月 2 場(chǎng)高質(zhì)量分享，點(diǎn)擊加入社群。

早在 2011 年，阿里巴巴內(nèi)部便開始了應(yīng)用容器化，當(dāng)時(shí)最開始是基于 LXC 技術(shù)構(gòu)建容器，然后逐漸切換到 Docker，自研了大規(guī)模編排調(diào)度系統(tǒng)。到了 2018 年，我們團(tuán)隊(duì)依托 K8s 體系開始推進(jìn)“輕量級(jí)容器化”，同時(shí)投入了工程力量跟開源社區(qū)一起解決了諸多規(guī)模與性能問(wèn)題，從而逐步將過(guò)去“類虛擬機(jī)”的運(yùn)維鏈路和阿里巴巴整體應(yīng)用基礎(chǔ)設(shè)施架構(gòu)升級(jí)到了云原生技術(shù)棧。

到了 2019 年，Kubernetes 基礎(chǔ)設(shè)施底盤在阿里巴巴經(jīng)濟(jì)體中已經(jīng)覆蓋了阿里巴巴方方面面的業(yè)務(wù)，規(guī)模化的接入了包括核心電商、物流、金融、外賣、搜索、計(jì)算、AI 等諸多頭部互聯(lián)網(wǎng)場(chǎng)景。這套技術(shù)底盤，也逐步成為了阿里巴巴支撐 618、雙11 等互聯(lián)網(wǎng)級(jí)大促的主力軍之一。

目前，阿里巴巴與螞蟻金服內(nèi)部運(yùn)行了數(shù)十個(gè)超大規(guī)模的 K8s 集群，其中大的集群約 1 萬(wàn)個(gè)機(jī)器節(jié)點(diǎn)，而其實(shí)這還不是能力上限。每個(gè)集群都會(huì)服務(wù)上萬(wàn)個(gè)應(yīng)用。在阿里云 Kubernetes 服務(wù)（ACK）上，我們還維護(hù)了上萬(wàn)個(gè)用戶的 K8s 集群，這個(gè)規(guī)模和其中的技術(shù)挑戰(zhàn)在全世界也是首屈一指的。

我們的 Kubernetes 面臨的新挑戰(zhàn)

在規(guī)模和性能等基礎(chǔ)設(shè)施領(lǐng)域問(wèn)題逐步解決的同時(shí)，規(guī)模化鋪開 Kubernetes 的過(guò)程中，我們逐步發(fā)現(xiàn)這套體系里其實(shí)還有很多意想不到的挑戰(zhàn)。這也是今天分享的主題。

第一個(gè)是 K8s 的 API 里其實(shí)并沒有“應(yīng)用”的概念

而且，Kubernetes API 的設(shè)計(jì)把研發(fā)、運(yùn)維還有基礎(chǔ)設(shè)施關(guān)心的事情全都糅雜在一起了。這導(dǎo)致研發(fā)覺得 K8s 太復(fù)雜，運(yùn)維覺得 K8s 的能力非常凌亂、零散，不好管理，只有基礎(chǔ)設(shè)施團(tuán)隊(duì)（也就是我們團(tuán)隊(duì)）覺得 Kubernetes 比較好用。但是基礎(chǔ)設(shè)施團(tuán)隊(duì)也很難跟研發(fā)和運(yùn)維解釋清楚 Kubernetes 的價(jià)值到底是什么。

我們來(lái)看個(gè)實(shí)際的例子。

就拿上圖中的 replica 為 3 來(lái)說(shuō)，開發(fā)人員怎么知道實(shí)例數(shù)應(yīng)該配幾個(gè)呢？如果運(yùn)維想要改replica，敢不敢改？能不能改？如果 replica 還能理解的話，那像 shareProcessNamespace 這種字段真是靈魂拷問(wèn)了。 開發(fā)人員僅從字面意思知道這個(gè)可能跟容器進(jìn)程共享有關(guān)，那么配置了這個(gè)應(yīng)用會(huì)有什么影響呢？會(huì)不會(huì)有安全問(wèn)題？

在阿里巴巴內(nèi)部，很多 PaaS 平臺(tái)只允許開發(fā)填 Deployment 的極個(gè)別字段。為什么允許填的字段這么少？是平臺(tái)能力不夠強(qiáng)嗎？其實(shí)不是的，本質(zhì)原因在于業(yè)務(wù)開發(fā)根本不想理解這眾多的字段。

所以這個(gè) PaaS 平臺(tái)只允許用戶填個(gè)別字段，其實(shí)反倒是幫助業(yè)務(wù)開發(fā)人員避免了這些靈魂拷問(wèn)。但反過(guò)來(lái)想，屏蔽掉大量字段真的就解決問(wèn)題了嗎？這種情況下，整個(gè)組織的基礎(chǔ)設(shè)施能力還如何演進(jìn)？應(yīng)用開發(fā)和應(yīng)用運(yùn)維人員的訴求又該怎么傳遞給基礎(chǔ)設(shè)施呢？

實(shí)際上，歸根到底，Kubernetes 是一個(gè) Platform for Platform 項(xiàng)目，它的設(shè)計(jì)是給基礎(chǔ)設(shè)施工程師用來(lái)構(gòu)建其他平臺(tái)用的（比如 PaaS 或者 Serverless），而不是直面研發(fā)和運(yùn)維同學(xué)的。從這個(gè)角度來(lái)看，Kubernetes 的 API，其實(shí)可以類比于 Linux Kernel 的 System Call，這跟研發(fā)和運(yùn)維真正要用的東西（Userspace 工具）完全不是一個(gè)層次上的。你總不能讓本來(lái)寫 Java Web 的同學(xué)每天直接調(diào)用著 Linux Kernel System Call，還給你點(diǎn)贊吧？

第二， K8s 實(shí)在是太靈活了，插件太多了，各種人員開發(fā)的 Controller 和 Operator 也非常多。

這種靈活性，讓我們團(tuán)隊(duì)開發(fā)各種能力很容易，但也使得對(duì)于應(yīng)用運(yùn)維來(lái)說(shuō)， K8s 的這些能力管理變得非常困難。比如一個(gè)環(huán)境里的不同運(yùn)維能力，實(shí)際上有可能是沖突的。

我們來(lái)看一個(gè)例子，基礎(chǔ)設(shè)施團(tuán)隊(duì)最近開發(fā)上線了一個(gè)新的插件，叫做 CronHPA，一個(gè)具體的 Spec 如下所示。

作為基礎(chǔ)設(shè)施團(tuán)隊(duì)，我們覺得這種 K8s 插件很簡(jiǎn)單， CRD 也很容易理解。就像這個(gè) CronHPA 的功能，從早上六點(diǎn)開始到下午七點(diǎn)鐘這個(gè)實(shí)例最少有 20 個(gè)、最多有 25 個(gè)，到第二天早上六點(diǎn)鐘最少 1 個(gè)、最多有 9 個(gè)，在每個(gè)階段會(huì)根據(jù) CPU 這個(gè)指標(biāo)衡量調(diào)整實(shí)例數(shù)。

然而，就在我們美滋滋的上線這個(gè)插件后不久，應(yīng)用運(yùn)維同學(xué)就開始跟我們抱怨了：

1. “這個(gè)能力到底該怎么使用呢？它的使用手冊(cè)在哪里？是看 CRD 還是看文檔呢？”
2. “我怎么知道這個(gè)插件在某個(gè)集群里有沒有裝好呢？”
3. “我們運(yùn)維不小心把 CronHPA 和 HPA 綁定給同一個(gè)應(yīng)用，結(jié)果發(fā)現(xiàn)這個(gè)應(yīng)用是會(huì)抽風(fēng)的。為什么你們 K8s 非要等到這種沖突發(fā)生的時(shí)候才報(bào)錯(cuò)呢？你們就不能設(shè)計(jì)個(gè)機(jī)制自動(dòng)檢查一下這些插件的使用過(guò)程有沒有發(fā)生沖突嗎？”其實(shí)這個(gè)我們后來(lái)確實(shí)做了，解決方法是給我們的 K8s 加了 20 多個(gè) Admission Hook。

第三，也是阿里巴巴上云之后我們團(tuán)隊(duì)特別痛的一個(gè)點(diǎn)。

我們需要處理的應(yīng)用的交付場(chǎng)景，除了公有云以外，還會(huì)有專有云、混合云、IoT 等各種復(fù)雜的環(huán)境。各種各樣的云服務(wù)在這種復(fù)雜場(chǎng)景下，連 API 都是不統(tǒng)一的，這個(gè)時(shí)候我們就需要專門的交付團(tuán)隊(duì)來(lái)進(jìn)行彌補(bǔ)，一個(gè)一個(gè)的去對(duì)接、去交付應(yīng)用。對(duì)他們來(lái)說(shuō)這是一件非常痛苦的事情：“不是說(shuō)好的 Docker 化了之后就能‘一次打包、隨處運(yùn)行’了嗎？”說(shuō)白了，K8s 現(xiàn)在并沒有一個(gè)統(tǒng)一的、平臺(tái)無(wú)關(guān)的應(yīng)用描述能力。

阿里巴巴的解決辦法

在 2019 年，我們團(tuán)隊(duì)開始思考如何通過(guò)技術(shù)手段解決上述應(yīng)用管理與交付相關(guān)的問(wèn)題，到現(xiàn)在已經(jīng)取得了一定的成果。

不過(guò)，在講解阿里巴巴如何解決上述問(wèn)題的方案之前，有必要先介紹一下我們推進(jìn)所有這些方案的理論基礎(chǔ)。在這里，我們主要遵循的是?CNCF 倡導(dǎo)的“應(yīng)用交付分層模型”，如下圖所示：

這個(gè)模型的基礎(chǔ)假設(shè)是：Kubernetes 本身并不提供完整的應(yīng)用管理體系。換句話說(shuō)，基于 K8s 的應(yīng)用管理體系，不是一個(gè)開箱即用的功能，而是需要基礎(chǔ)設(shè)施團(tuán)隊(duì)基于云原生社區(qū)和生態(tài)自己構(gòu)建出來(lái)的。這里面就需要引入很多開源項(xiàng)目或者能力。

而上面這個(gè)模型的一個(gè)重要作用，就是能夠把這些項(xiàng)目和能力以及它們的協(xié)作關(guān)系，非常清晰地分類和表達(dá)出來(lái)。

• 比如 Helm 就是位于整個(gè)應(yīng)用管理體系的最上面，也就是第 1 層，還有 Kustomize 等各種 YAML 管理工具，CNAB 等打包工具，它們都對(duì)應(yīng)在第 1.5 層；

• 然后有 Tekton、Flagger 、Kepton 等應(yīng)用交付項(xiàng)目，包括發(fā)布部署的流程，配置管理等，目前比較流行的是基于 GitOps 的管理，通過(guò) git 作為“the source of truth”，一切都面向終態(tài)、透明化的管理，也方便對(duì)接，對(duì)應(yīng)在第 2 層；

• 而 Operator 以及 K8s 的各種工作負(fù)載組件（Deployment、StatefulSet?等），具體來(lái)說(shuō)就像某個(gè)實(shí)例掛了這些組件自動(dòng)拉起來(lái)一個(gè)彌補(bǔ)上原來(lái)所需要三個(gè)的實(shí)例數(shù)，包括一些自愈、擴(kuò)縮容等能力，對(duì)應(yīng)在第 3 層；

• 最后一層則是平臺(tái)層，包括了所有底層的核心功能，負(fù)責(zé)對(duì)工作負(fù)載的容器進(jìn)行管理、封裝基礎(chǔ)設(shè)施能力、對(duì)各種不同的工作負(fù)載對(duì)接底層基礎(chǔ)設(shè)施提供 API 等。

這些層次之間，通過(guò)相互之間的緊密協(xié)作，共同構(gòu)建出一套高效、簡(jiǎn)潔的應(yīng)用管理與交付體系。在這些層次當(dāng)中，目前阿里巴巴在今年 KubeCon 時(shí)已經(jīng)宣布開源了第三層的 OpenKruise 項(xiàng)目。最近，我們則正在聯(lián)合微軟等更廣泛的生態(tài)，和整個(gè)社區(qū)一起推進(jìn)第一層“應(yīng)用定義”相關(guān)的工作。

應(yīng)用定義到底該怎么做？

其實(shí)，關(guān)于應(yīng)用定義，無(wú)論是開源社區(qū)還是在阿里巴巴內(nèi)部，都已經(jīng)做了不少嘗試，比如一開始我提到 Docker 解決了單機(jī)應(yīng)用交付，它就通過(guò) Docker 鏡像把單機(jī)應(yīng)用定義的很好。

圍繞 Kubernetes 我們也試過(guò)使用 Helm 以及 Application CRD 來(lái)定義應(yīng)用。但是現(xiàn)在的云原生應(yīng)用，往往會(huì)依賴云上的資源，像數(shù)據(jù)庫(kù)會(huì)依賴 RDS、訪問(wèn)會(huì)依賴 SLB，Helm 和 Application CRD 只是單純地將 K8s 的 API 組合在一起，無(wú)法描述我們對(duì)云上面資源的依賴，當(dāng)我們用 CRD 來(lái)描述云上資源依賴的時(shí)候，它其實(shí)是 freestyle 的，沒有一個(gè)很好的規(guī)范和約束，無(wú)論是用戶、開發(fā)、運(yùn)維還是平臺(tái)資源提供方都沒有一個(gè)共識(shí)，自然也就無(wú)法協(xié)作和復(fù)用。

另一方面，它們既然是簡(jiǎn)單的對(duì) K8s API 的組合，那么 K8s API 本身“不面向應(yīng)用研發(fā)和運(yùn)維設(shè)計(jì)”的問(wèn)題就依然存在，這并不符合我們所希望的“應(yīng)用定義”應(yīng)該走的方向。此外，像 Application CRD，它雖然是 K8s 社區(qū)的項(xiàng)目，但是卻明顯缺乏社區(qū)活躍度，大多數(shù)修改都停留在一年前。

試了一圈，我們發(fā)現(xiàn)“應(yīng)用定義”這個(gè)東西，在整個(gè)云原生社區(qū)里其實(shí)是缺失的。這也是為什么阿里巴巴內(nèi)部有很多團(tuán)隊(duì)開始嘗試設(shè)計(jì)了自己的“定義應(yīng)用”。簡(jiǎn)單地說(shuō)，這個(gè)設(shè)計(jì)其實(shí)就是把應(yīng)用本身的鏡像、啟動(dòng)參數(shù)、依賴的云資源等等全部描述起來(lái)，分門別類的進(jìn)行放置，并通過(guò)一個(gè)模板，最終渲染出一個(gè)配置文件，文件里有上千個(gè)字段，完整描述了一個(gè)應(yīng)用定義的所有內(nèi)容。這個(gè)配置文件大概長(zhǎng)下面這個(gè)樣子：

除了基本的 Deployment?描述字段，這種 in-house 應(yīng)用定義往往還會(huì)包含云上資源的聲明，比如使用哪種 ECS 套餐、如何續(xù)費(fèi)、使用的是哪種磁盤和規(guī)格等等一系列額外的描述。這些資源的定義是一大塊，并且上面的例子里我們已經(jīng)盡量精簡(jiǎn)了；另一大塊就是運(yùn)維能力的描述，比如自動(dòng)擴(kuò)縮容、流量切換、灰度、監(jiān)控等，涉及到一系列的規(guī)則。

然而，你也不難看到，這種定義方式最終所有的配置還是會(huì)全部堆疊到一個(gè)文件里，這跟 K8s API all-in-one 的問(wèn)題是一樣的，甚至還更嚴(yán)重了。而且，這些應(yīng)用定義最終也都成為了黑盒，除了對(duì)應(yīng)項(xiàng)目本身可以使用，其他系統(tǒng)基本無(wú)法復(fù)用，自然就更無(wú)法使得多方協(xié)作復(fù)用了。

吸取了這些教訓(xùn)以后，我們團(tuán)隊(duì)決定從另一個(gè)方向開始設(shè)計(jì)一個(gè)新的應(yīng)用定義。

具體來(lái)說(shuō)，相比于其他“應(yīng)用定義”給 K8s 做加法、做整合的思路，我們認(rèn)為，真正良好的應(yīng)用定義，應(yīng)該給 K8s API 做“減法”。更準(zhǔn)確的說(shuō)，是我們應(yīng)該通過(guò)“做減法”，把開發(fā)者真正關(guān)心的 API 給暴露出來(lái)，把運(yùn)維、平臺(tái)關(guān)心的 API 給封裝起來(lái)。

也就是說(shuō)，既然 K8s API 為了方便基礎(chǔ)設(shè)施工程師，已經(jīng)選擇把各方的關(guān)注點(diǎn)混在了一起。那么，當(dāng)基礎(chǔ)設(shè)施工程師想要基于 K8s 來(lái)服務(wù)更上層應(yīng)用開發(fā)和運(yùn)維人員時(shí)，其實(shí)應(yīng)該考慮把這些關(guān)注點(diǎn)重新梳理出來(lái)，讓應(yīng)用管理的各個(gè)參與方重新拿到屬于自己的 API 子集。

所以，我們開始在 K8s API 的基礎(chǔ)上增加了一層很薄的抽象，從而把原始的 K8s API 按照現(xiàn)實(shí)中的協(xié)作邏輯進(jìn)行合理的拆分和分類，然后分別暴露給研發(fā)和運(yùn)維去使用。這里的原則是：研發(fā)拿到的 API 一定是研發(fā)視角的、沒有任何基礎(chǔ)設(shè)施的概念在里面；而運(yùn)維拿到的 API，一定是對(duì) K8s 能力的模塊化、聲明式的描述。這樣，在理想情況下，運(yùn)維（或者平臺(tái)）就能夠?qū)@些來(lái)自雙方的 API 對(duì)象進(jìn)行組合，比如：應(yīng)用 A + Autoscaler X，應(yīng)用 B + Ingress Y。這樣組合完成后的描述對(duì)象，其實(shí)就可以完整的來(lái)描述“應(yīng)用”這個(gè)東西了。

Open Application Model （OAM）

在同社區(qū)進(jìn)行交流和驗(yàn)證中，我們發(fā)現(xiàn)：上面的這個(gè)思路正好跟當(dāng)時(shí)微軟 Brendan Burns （Kubernetes 項(xiàng)目創(chuàng)始人）和 Matt Butcher （Helm 項(xiàng)目創(chuàng)始人）團(tuán)隊(duì)的思路不謀而合。所以我們雙方在面對(duì)面交流了幾次之后，很快就決定共建這個(gè)項(xiàng)目并把它開源出來(lái)，跟整個(gè)社區(qū)生態(tài)一起來(lái)推進(jìn)這件非常具有意義的事情。

今年 10 月 17 號(hào)，阿里云小邪和微軟云 CTO Mark 共同對(duì)外宣布了這個(gè)項(xiàng)目的開源，它的官方名字叫做 Open Application Model（OAM），同時(shí)我們還宣布了 OAM 對(duì)應(yīng)的 K8s 實(shí)現(xiàn)——Rudr 項(xiàng)目。

具體來(lái)說(shuō)，在設(shè)計(jì) OAM 的時(shí)候，我們希望這個(gè)應(yīng)用定義應(yīng)該解決傳統(tǒng)應(yīng)用定義的三個(gè)問(wèn)題：

• 第一，不能有運(yùn)行時(shí)鎖定。一套應(yīng)用定義，必須可以不加修改跑到不同運(yùn)行環(huán)境當(dāng)中，無(wú)論是不是基于 K8s，這是解決我們?cè)趹?yīng)用交付時(shí)所遇到的問(wèn)題的關(guān)鍵。這才是真正的“一次定義、隨處運(yùn)行”；

• 第二，這個(gè)應(yīng)用定義必須要區(qū)分使用角色，而不是繼續(xù)延續(xù) K8s 的 all-in-one API。 我們已經(jīng)深刻了解到，我們所服務(wù)的應(yīng)用開發(fā)人員，實(shí)際上很難、也不想關(guān)心運(yùn)維以及 K8s 底層的各種概念，我們不應(yīng)該讓他們?cè)疽呀?jīng)很苦逼的日子變得更糟；

• 最后一個(gè)，這個(gè)應(yīng)用定義必須不是在一個(gè) YAML 里描述所有東西。一旦一個(gè)應(yīng)用定義里把所有信息全部耦合在一起，就會(huì)造成應(yīng)用描述和運(yùn)維描述被雜糅在一起，從而導(dǎo)致這個(gè)定義的復(fù)雜度成倍提升，也會(huì)讓這個(gè)定義完全無(wú)法復(fù)用。我們希望這些不同領(lǐng)域的描述能夠分開，然后平臺(tái)可以自由地組合搭配。

在這個(gè)思路下，我們最后設(shè)計(jì)出來(lái)的應(yīng)用定義主要分為三個(gè)大塊：

• 第一部分是應(yīng)用組件的描述，包括應(yīng)用組件怎么運(yùn)行和該組件所依賴的各種資源。這個(gè)部分是開發(fā)負(fù)責(zé)編寫的；

• 第二部分是運(yùn)維能力的描述，比如應(yīng)用怎么 scale、怎么訪問(wèn)、怎么升級(jí)等策略。這個(gè)部分是運(yùn)維負(fù)責(zé)編寫的；

• 第三部分是把上述描述文件組合在一起的一個(gè)配置文件。比如：“ 一個(gè)應(yīng)用有兩個(gè)組件，組件 A 需要運(yùn)維能力 X 和能力 Y，組件 B 需要運(yùn)維能力 X”。所以這個(gè)配置文件，其實(shí)才是最終的“應(yīng)用”。這個(gè)配置文件，也是運(yùn)維編寫，并且提交給平臺(tái)去運(yùn)行的，當(dāng)然，平臺(tái)也可以自動(dòng)生成這個(gè)文件。

下面我們通過(guò)實(shí)例來(lái)看下以上三個(gè)部分對(duì)應(yīng)的 YAML 文件到底長(zhǎng)什么樣子？它們究竟怎么玩兒？

備注：如果你想跟我一樣實(shí)際操作體驗(yàn)這個(gè)流程，你只需要在 K8s 集群里裝上 Rudr 項(xiàng)目就可以實(shí)操了。

第一部分：Component

首先我們可以看到，Component 定義的是開發(fā)關(guān)心的事情，沒有任何運(yùn)維相關(guān)的概念。

它的 Spec 主要分為兩大塊：

第一個(gè)參數(shù)塊是應(yīng)用描述，包括 WorkloadType 字段，這個(gè)字段就是表達(dá)應(yīng)用使用什么 Workload 運(yùn)行，在我們?cè)O(shè)計(jì)里有六種默認(rèn) Workload，分別是 Server、Worker、Job 以及他們對(duì)應(yīng)的單例模式，Workload 也可以擴(kuò)展。Server 代表這是一個(gè)可以自動(dòng)伸縮的，并且有一個(gè)端口可以訪問(wèn)的模式。接下來(lái)就是容器的鏡像、啟動(dòng)參數(shù)之類的，這部分包含完整的 OCI spec。

第二塊是 parameters 如何運(yùn)行可擴(kuò)展的參數(shù)，如環(huán)境變量和端口號(hào)。這一塊參數(shù)的特點(diǎn)是：它們雖然是開發(fā)定義的，但是都允許運(yùn)維后續(xù)覆蓋。這里的關(guān)鍵點(diǎn)是，關(guān)注點(diǎn)分離并不等于完全割裂。所以，我們?cè)O(shè)計(jì)了 parameters 列表，其實(shí)就是希望開發(fā)能告訴運(yùn)維，哪些參數(shù)后續(xù)可以被運(yùn)維人員覆蓋掉。這樣的話就很好地聯(lián)動(dòng)起來(lái)了，開發(fā)人員可以向運(yùn)維人員提出訴求，比如運(yùn)維應(yīng)該使用哪些參數(shù)、參數(shù)代表什么意思。

像這樣一個(gè) Component 可以直接通過(guò) kubectl 安裝到 K8s 中。

然后我們可以通過(guò) kubectl 工具查看到已經(jīng)安裝好的組件有哪些：

所以說(shuō)，我們當(dāng)前的 K8s 集群，支持兩種“應(yīng)用組件”。需要指出的是，除了我們內(nèi)置支持的組件之外，開發(fā)自己可以自由定義各種各樣的組件然后提交給我們。Component Spec 里的 Workload Type 是可以隨意擴(kuò)展的，就跟 K8s 的 CRD 機(jī)制一樣。

第二部分： Trait

說(shuō)完了開發(fā)能用的 API，我們?cè)賮?lái)看運(yùn)維用的 API 長(zhǎng)什么樣。

在設(shè)計(jì)應(yīng)用的運(yùn)維能力定義的過(guò)程中，我們重點(diǎn)關(guān)注的是運(yùn)維能力怎么發(fā)現(xiàn)和管理的問(wèn)題。

為此，我們?cè)O(shè)計(jì)了一個(gè)叫做 Trait 的概念。所謂 Trait，也就是應(yīng)用的“特征”，其實(shí)就是一種運(yùn)維能力的聲明式描述。我們能通過(guò)命令行工具發(fā)現(xiàn)一個(gè)系統(tǒng)里支持哪些 Traits（運(yùn)維能力）。

這時(shí)候，運(yùn)維要查看具體的運(yùn)維能力該怎么使用，是非常簡(jiǎn)單的：

可以看到，他可以在 Trait 定義里清晰的看到這個(gè)運(yùn)維能力可以作用于哪種類型的 Workload，包括能填哪些參數(shù)？哪些必填？哪些選填？參數(shù)的作用描述是什么？ 你也可以發(fā)現(xiàn)，OAM 體系里面，Component 和 Trait 這些 API 都是 Schema，所以它們是整個(gè)對(duì)象的字段全集，也是了解這個(gè)對(duì)象描述的能力“到底能干嗎？”的最佳途徑（反正基礎(chǔ)設(shè)施團(tuán)隊(duì)的文檔寫的也不咋地）。

上面這些 Trait 也都是用過(guò) kubectl apply 就可以安裝到集群當(dāng)中的。

既然 Component 和 Trait 都是 Schema，那么它們?cè)趺磳?shí)例化成應(yīng)用呢？

第三部分：Application Configuration

在 OAM 體系中，Application Configuration 是運(yùn)維人員（或者系統(tǒng)本身也可以）執(zhí)行應(yīng)用部署等動(dòng)作的操作對(duì)象。在 Application Configuration 里，運(yùn)維人員可以將 Trait 綁定到 Component 上執(zhí)行。

在 Application Configuration YAML 里面，運(yùn)維可以把 Component 和 Trait 組裝起來(lái)，從而得到一個(gè)可以部署的“應(yīng)用”：

在這里我們可以看到，運(yùn)維實(shí)例化的應(yīng)用里面包含了一個(gè)叫 hellowworld-python-v1 的 Component，它有兩個(gè)參數(shù)：一個(gè)是環(huán)境變量 target，一個(gè)是port。需要注意的是，這兩個(gè)參數(shù)是運(yùn)維人員覆蓋了原先 Component yaml 中開發(fā)定義的兩個(gè)可覆蓋變量。

同時(shí)，這個(gè) Component 綁定了 2 個(gè)運(yùn)維能力：一個(gè)是水平擴(kuò)容，一個(gè)是 Ingress 域名訪問(wèn)。

運(yùn)維人員通過(guò) kubectl 即可把這樣一個(gè)應(yīng)用部署起來(lái)：

這時(shí)候在 K8s 里面，你就可以看到 OAM 插件會(huì)自動(dòng)為你創(chuàng)建出對(duì)應(yīng)的 Deployment。

同時(shí)，這個(gè)應(yīng)用需要的 Ingress 也被自動(dòng)創(chuàng)建起來(lái)了：

這里其實(shí)是前面提到的 Rudr 插件在起作用，在拿到 OAM 的 Application Configuration 文件以后，識(shí)別出其中的 Component 和 Trait，將其映射到 K8s 上的資源并拉起，K8s 資源相應(yīng)的生命周期都隨著 OAM 的配置去管理。當(dāng)然，由于 OAM 定義是平臺(tái)無(wú)關(guān)的，所以除了 K8s 本身的資源，Rudr 插件的實(shí)現(xiàn)中也會(huì)加入外部資源的拉起。

OAM YAML 文件 = 一個(gè)自包含的軟件安裝包

最終我們可以通過(guò)像樂高積木一樣組裝復(fù)用 OAM 的不同模塊，實(shí)例化出一個(gè) OAM 的應(yīng)用出來(lái)。更重要的是，這個(gè) OAM 應(yīng)用描述文件是完全自包含的，也就是說(shuō)通過(guò) OAM YAML，作為軟件分發(fā)商，我們就可以完整地跟蹤到一個(gè)軟件運(yùn)行所需要的所有資源和依賴。

這就使得現(xiàn)在對(duì)于一個(gè)應(yīng)用，大家只需要一份 OAM 的配置文件，就可以快速、在不同運(yùn)行環(huán)境上把應(yīng)用隨時(shí)運(yùn)行起來(lái)，把這種自包含的應(yīng)用描述文件完整地交付到任何一個(gè)運(yùn)行環(huán)境中。

這不僅讓我們前面提到的軟件交付難題得到了很好的解決，也讓更多非 K8s 平臺(tái)比如?IoT、游戲分發(fā)、混合環(huán)境軟件交付等場(chǎng)景，能享受到云原生應(yīng)用管理的暢快。

最后

OAM 是一個(gè)完全屬于社區(qū)的應(yīng)用定義模型，我們非常希望大家都能參與進(jìn)來(lái)。

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

• 一方面，如果你有任何場(chǎng)景感覺 OAM 無(wú)法滿足的，歡迎你在社區(qū)提出 issue 來(lái)描述你的案例；

• 另一方面，OAM 模型也正在積極的同各個(gè)云廠商、開源項(xiàng)目進(jìn)行對(duì)接。

我們期待能與大家一起共建這個(gè)全新的應(yīng)用管理生態(tài)。

Q & A

Q1：OAM?spec 中目前還沒有看到屬于 Infra Operator 的管理對(duì)象（補(bǔ)充：Component 是面向 App Developer，Traits 和 AppConfiguration 面向 App Operator，哪個(gè)對(duì)象是面向 Infra Operator 的？）
A1：OAM 本身就是基礎(chǔ)設(shè)施運(yùn)維手里的武器，包括 Kubernetes、Terraform 等一系列平臺(tái)層的開源項(xiàng)目，基礎(chǔ)設(shè)施運(yùn)維可以通過(guò)這些開源項(xiàng)目構(gòu)建 OAM 的實(shí)現(xiàn)（如 Rudr 基于 Kubernetes）。所以 OAM 的實(shí)現(xiàn)層就是基礎(chǔ)設(shè)施運(yùn)維提供的，他們不需要額外的對(duì)象來(lái)使用 OAM。

Q2：OAM Controller和 admission controller 的分工標(biāo)準(zhǔn)是什么？
A2：OAM 項(xiàng)目中的 admission controller 用于轉(zhuǎn)換和檢驗(yàn) spec，完全等價(jià)于 K8s 中 admission controller。目前實(shí)現(xiàn)的功能包括轉(zhuǎn)換 [fromVariable(VAR)] 這種 spec 中的函數(shù)，檢驗(yàn) AppConfig、Component、Trait、Scope 等 CR 是否符合規(guī)范，是否合法等。OAM Controller，即目前的開源項(xiàng)目 Rudr，就是整個(gè) OAM 的實(shí)現(xiàn)層，它負(fù)責(zé)解釋 OAM 的 spec 并轉(zhuǎn)換為真實(shí)運(yùn)行的資源，這里的資源可以是 K8s 原有的一些，也可以是像阿里云上的 RDS 這類云資源。目前 Rudr 項(xiàng)目是 Rust 語(yǔ)言寫的，考慮到 K8s 生態(tài)大多數(shù)都是用 Go 語(yǔ)言寫的，我們后續(xù)也會(huì)開源一個(gè) Go 語(yǔ)言編寫的 OAM-Framework，用于快速實(shí)現(xiàn)像 Rrudr 這樣的 OAM 實(shí)現(xiàn)層。

Q3：計(jì)劃啥時(shí)候開源 Go 的?OAM-Framework 呀？
A3：我們需要一點(diǎn)時(shí)間進(jìn)一步打磨 OAM-Framework ，讓它適配大家的場(chǎng)景。但是應(yīng)該很快就會(huì)跟大家見面。

Q4：阿里是如何降低 K8s 的復(fù)雜度來(lái)滿足運(yùn)維和研發(fā)一些共性訴求的？在 K8s 中的用戶 user 角色可能是開發(fā)也可能是運(yùn)維。
A4：目前我們遇到的大多數(shù)場(chǎng)景都能區(qū)分哪些是運(yùn)維要關(guān)心的，哪些是研發(fā)要關(guān)心的。OAM 降低 K8s 復(fù)雜度的主要方法就是關(guān)注點(diǎn)分離，給 K8s 的 API 做減法，盡量讓某一方可以少關(guān)注一些內(nèi)容。如果你有這樣一個(gè)無(wú)法分割的場(chǎng)景，其實(shí)我們也很感興趣，歡迎把 case 提出來(lái)一起探討。另一方面，我們并不是屏蔽掉 K8s，OAM Spec 預(yù)留了充足的擴(kuò)展性，完全可以把K8s原有的能力提供給用戶。

Q5：我認(rèn)為 OAM 是基于 K8s 針對(duì)于不同應(yīng)用上的抽象層，現(xiàn)在我們有很多應(yīng)用都是用 Helm 包包裝好的，如果切換成 OAM 的話，我們需要注意哪些地方呢？
A5：其實(shí)我們上半年一直在推廣 Helm 在國(guó)內(nèi)的使用，包括提供了阿里巴巴的 Helm 鏡像站（https://developer.aliyun.com/hub）等，所以 OAM 跟 Helm 也是相輔相成的。簡(jiǎn)單的說(shuō)，OAM 其實(shí)就是 Helm 包里面 template 文件夾里面的內(nèi)容。Helm 是 OAM 做參數(shù)渲染（template）和打包（chart）的工具。如果切換到 OAM，Helm 的使用方式不需要變，里面的 spec 換成 OAM 的 spec 即可。

Q6：請(qǐng)問(wèn)，Rudr 用起來(lái)了嗎，效果如何。Rudr 的架構(gòu)有沒更豐富的資料？
A6：Rudr?一直是可以用的，大家要是用不起來(lái)可以提 issue，想要什么方面的資料或者疑問(wèn)也可以提 issue，我們也在完善文檔。目前相關(guān)的材料都在這里：
https://github.com/oam-dev/rudr/tree/master/docs

Q7：我們一直在用 Helm 打包我們的應(yīng)用，去做 gitops ，一個(gè)通用的 chart 對(duì)應(yīng)不同的 values.yaml 做到了復(fù)用。聽了分享，很期待 OAM，當(dāng)然還有 Openkruise。<br />A7：Openkruise 是開源的哈，大家可以關(guān)注?https://github.com/openkruise/kruise?我們也一直在迭代。

Q8：OAM?有哪些公司在用？實(shí)際體驗(yàn)反饋如何？
A8：OAM 剛剛發(fā)布一個(gè)月左右，具體有哪些公司已經(jīng)在使用我們還沒有來(lái)得及統(tǒng)計(jì)。阿里巴巴和微軟內(nèi)部都已經(jīng)在使用，并且都有對(duì)外的產(chǎn)品使用 OAM。就我們接觸到的用戶來(lái)說(shuō)，無(wú)論是社區(qū)的用戶還是阿里巴巴內(nèi)部，都對(duì) OAM 的關(guān)注點(diǎn)分離等理念非常認(rèn)同，也都在積極落地。

---

社群分享文章整理

Vol 1?: 當(dāng) K8s 集群達(dá)到萬(wàn)級(jí)規(guī)模，阿里巴巴如何解決系統(tǒng)各組件性能問(wèn)題？

Vol 2?: 超大規(guī)模商用 K8s 場(chǎng)景下，阿里巴巴如何動(dòng)態(tài)解決容器資源的按需分配問(wèn)題？

Vol 3?: 備戰(zhàn)雙 11！螞蟻金服萬(wàn)級(jí)規(guī)模 K8s 集群管理系統(tǒng)如何設(shè)計(jì)？

Vol 4?: 帶你上手一款下載超 10 萬(wàn)次的?IEDA?插件

“ 阿里巴巴云原生微信公眾號(hào)（ID：Alicloudnative）關(guān)注微服務(wù)、Serverless、容器、Service Mesh等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢(shì)、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開發(fā)者的技術(shù)公眾號(hào)。”

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無(wú)理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國(guó)服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡(jiǎn)單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢(shì)，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場(chǎng)景需求。

網(wǎng)頁(yè)題目：給K8sAPI“做減法”：阿里巴巴云原生應(yīng)用管理的挑戰(zhàn)和實(shí)踐-創(chuàng)新互聯(lián)
當(dāng)前鏈接：http://chinadenli.net/article2/hjgoc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供小程序開發(fā)、云服務(wù)器、網(wǎng)站收錄、域名注冊(cè)、面包屑導(dǎo)航、營(yíng)銷型網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)