OAM是阿里巴巴與微軟聯(lián)合推出的開放應(yīng)用模型，旨在解耦應(yīng)用研發(fā)、應(yīng)用運(yùn)維與基礎(chǔ)設(shè)施人員在應(yīng)用生命周期中各自的關(guān)注點(diǎn)，明晰責(zé)任與界限，聚焦自身業(yè)務(wù)，同時(shí)又依然能緊密協(xié)作。當(dāng)前云原生DevOps體系現(xiàn)狀如何?面臨哪些挑戰(zhàn)?如何通過OAM解決云原生DevOps場(chǎng)景下的諸多問題?云原生開發(fā)應(yīng)用模型OAM(Open Application Model)社區(qū)核心成員孫健波將為大家一一解答，并分享如何基于OAM和Kubernetes打造無限能力的下一代DevOps平臺(tái)。

一 什么是DevOps?為什么基于Kubernetes構(gòu)建?

2009年舉辦了第一屆DevOpsDays大會(huì)，DevOps名字被首次提出。到2010年，DevOps的概念越來越火，出了What is DevOps的文章，講解了DevOps的概念，方法論及配套的工具。簡(jiǎn)單來說，研發(fā)工程師需要和運(yùn)維工程師深度的合作，同時(shí)通過一系列工具保證研發(fā)更加順暢，從而更容易的接觸生產(chǎn)環(huán)境。到2013年，Docker出現(xiàn)了，工程師可以第一次到軟件生產(chǎn)環(huán)境中定義，通過Docker image完成單機(jī)軟件的交付和分發(fā)。此時(shí)DevOps開始慢慢落地。2015年開始，DevOps相關(guān)的工具越來越多，資源利用率出現(xiàn)了一些問題，CNCF的成立使得DevOps的實(shí)踐往Kubernetes上走。

??

DevOps的三個(gè)階段

阿里在Kubernetes上的實(shí)踐也取得了非常好的成果。在規(guī)模方面，阿里內(nèi)部集成了數(shù)十個(gè)節(jié)點(diǎn)可以達(dá)到上萬的集群，同時(shí)具備高性能和安全特性，秒級(jí)擴(kuò)容，神龍+安全容器。具備極致的彈性，分鐘級(jí)拆解公有云計(jì)算資源，無限資源池。另一方面，Kubernetes社區(qū)已經(jīng)具備非常豐富的DevOps生態(tài)基礎(chǔ)功能，包括鏡像托管、CI\CD流水線、任務(wù)編排、發(fā)布策略、鏡像打包、分發(fā)、豐富的應(yīng)用運(yùn)行時(shí)的負(fù)載支撐、豐富彈性和應(yīng)用擴(kuò)容能力。

為什么阿里基于Kubernetes構(gòu)建DevOps平臺(tái)?

1)阿里基于Kubernetes的無限資源池與基礎(chǔ)設(shè)施能力

• 大規(guī)模 – 單集群最高可達(dá)10000節(jié)點(diǎn)、百萬Pod
• 高性能 – 秒級(jí)擴(kuò)容，智能伸縮，神龍 + 安全容器
• 極致彈性 – 分鐘級(jí)拆解公有云計(jì)算資源，無限資源池

2)社區(qū)圍繞Kubernetes已經(jīng)具備豐富的DevOps生態(tài)基礎(chǔ)功能

• 源碼到容器鏡像倉庫，Kubernetes是容器平臺(tái)事實(shí)標(biāo)準(zhǔn)：Github/DockerHub
• CI/CD流水線、任務(wù)編排、發(fā)布策略：Argo/Teckton/Spinnaker/Jenkins-X/Flagger
• 鏡像打包、分發(fā)：Helm/CNAB
• 豐富的應(yīng)用運(yùn)行負(fù)載支撐：Deployment(無狀態(tài))/StatefulSet(有狀態(tài))/OpenKruise(原生有狀態(tài)增強(qiáng))
• 豐富的彈性和應(yīng)用擴(kuò)縮容能力：HPA/KEDA

二 基于Kubernetes的DevOps平臺(tái)新挑戰(zhàn)

下圖展示了一個(gè)云原生下的DevOps流水線的典型流程。首先是代碼的開發(fā)，代碼托管到Github，再接入單元測(cè)試的工具Jenkins，此時(shí)基本研發(fā)已完成。再接著到鏡像的構(gòu)建，涉及到配置、編排等。云原生中可以用HELM打包應(yīng)用。打包好的應(yīng)用部署到各個(gè)環(huán)境中。但整個(gè)過程中會(huì)面臨很多挑戰(zhàn)。首先，在不同的環(huán)境需要不同的運(yùn)維能力。

??

一個(gè)云原生 DevOps 流水線的典型流程

其次，配置的過程中要?jiǎng)?chuàng)建云上數(shù)據(jù)庫，需要另外打開一個(gè)控制臺(tái)來創(chuàng)建數(shù)據(jù)庫。還需要配置負(fù)載均衡。在應(yīng)用啟動(dòng)以后還需要配置額外的功能，包括日志、策略、安全防護(hù)等等?？梢园l(fā)現(xiàn)，云資源和DevOps平臺(tái)體驗(yàn)是割裂的，里面充斥著借助外部平臺(tái)創(chuàng)建的過程。這對(duì)新手來說是非常痛苦的。

挑戰(zhàn)一：云資源與 DevOps 平臺(tái)體驗(yàn)割裂

DevOps流程中充斥著大量需要外部平臺(tái)創(chuàng)建的過程：

??

挑戰(zhàn)二：研發(fā)、運(yùn)維、基礎(chǔ)設(shè)施關(guān)注點(diǎn)耦合

下圖是常用的K8s的YAML配置文件，大家經(jīng)常吐槽這個(gè)配置文件很復(fù)雜。簡(jiǎn)單來說YAML配置文件可以分為三大塊，一塊是運(yùn)維比較關(guān)心的配置，包括實(shí)例數(shù)，策略和發(fā)布。第二塊是研發(fā)關(guān)心的，涉及到鏡像、端口號(hào)等。第三塊是基礎(chǔ)設(shè)施工程師看得懂的，如調(diào)度策略等。K8s的配置文件中將方方面面的信息都耦合在一起，這對(duì)K8s工程師來說是非常適合的，但是對(duì)應(yīng)用側(cè)的終端工程師而言，有很多不需要關(guān)心的配置指標(biāo)。

??

• DevOps流程中缺乏對(duì)“應(yīng)用”這個(gè)概念的描述
• K8s 的 YAML文件的定位并不是終端用戶

挑戰(zhàn)三：平臺(tái)的自定義封裝，簡(jiǎn)單卻能力不足

DevOps平臺(tái)對(duì)K8s能力封裝抽象，只剩下5個(gè)Deployment的字段需要研發(fā)填寫。從用戶角度而言，這種設(shè)置非常好用簡(jiǎn)單。但是針對(duì)稍微復(fù)雜的應(yīng)用，涉及到應(yīng)用狀態(tài)管理，健康檢查等等一系列的操作，此時(shí)這5個(gè)字段是不夠的。

??

挑戰(zhàn)四：CRD 擴(kuò)展能力強(qiáng)大，DevOps 平臺(tái)無法直接復(fù)用

CRD(Customize Resource Definition)擴(kuò)展能力強(qiáng)大，幾乎所有軟件都可以通過CRD的方式進(jìn)行擴(kuò)展，包括數(shù)據(jù)庫、存儲(chǔ)、安全、編排、依賴管理、發(fā)布等。但是對(duì)DevOps平臺(tái)來說，上面接口并沒有向用戶暴露，導(dǎo)致無法直接復(fù)用。

??

挑戰(zhàn)五：DevOps 平臺(tái)開發(fā)的新能力使用門檻高

如果平臺(tái)想要擴(kuò)展一些能力，而原生的自動(dòng)擴(kuò)縮容能力不太合適，希望開發(fā)定時(shí)的擴(kuò)縮容YAML文件，隨著業(yè)務(wù)情況而設(shè)置。但此時(shí)用戶使用YAML的門檻非常高，不清楚如何使用YAML。隨著新能力開發(fā)越來越多，能力之間會(huì)出現(xiàn)沖突，這也非常難以管理。

??

CronHPA

• 運(yùn)維同學(xué)怎么知道這個(gè)擴(kuò)展能力怎么用?

• 看 CRD?看配置文件?看 …… 文檔?

• 擴(kuò)展能力間出現(xiàn)沖突，導(dǎo)致線上故障

• 比如：CronHPA 和 默認(rèn) HPA 被同時(shí)安裝給了同一個(gè)應(yīng)用
• K8s 擴(kuò)展能力之間的沖突關(guān)系，如何有效管理?如何有效的對(duì)運(yùn)維透出?

挑戰(zhàn)六：不同 DevOps 平臺(tái)需要完全重新對(duì)接

很多云原生實(shí)踐中會(huì)遇到的問題，即需要定義非常復(fù)雜的YAML，這種方式可以解決企業(yè)內(nèi)部所有問題，但是挑戰(zhàn)在于很難與生態(tài)進(jìn)行對(duì)接。如RDS，SLB的能力都嵌到Y(jié)AML文件中，無法復(fù)用，幾乎不具備原子化能力。同時(shí)無法協(xié)作，無法提供給兄弟部門或生態(tài)使用，只能給內(nèi)部封閉生態(tài)使用。上層系統(tǒng)不同應(yīng)用對(duì)接DevOps平臺(tái)時(shí)，需要寫不同格式的YAML，這也是非常痛苦的。

??

• 難以理解，必須通過界面可視化透出
• 無法復(fù)用，幾乎不具備原子化能力
• 無法協(xié)作，只能內(nèi)部封閉生態(tài)使用

三 OAM應(yīng)用模型的技術(shù)原理

Component組件

OAM中常見的概念是Component組件，完全從研發(fā)角度定義的待部署單元。下圖右側(cè)是YAML中Component的例子，其中黃色部分可以靈活自定義。OAM中會(huì)定義標(biāo)準(zhǔn)的架構(gòu)ContaineriseWorkload，表示工作負(fù)載部分，里面是待部署單元的具體描述。這時(shí)就可以解決關(guān)注點(diǎn)分離的問題，幫助應(yīng)用側(cè)工程師去掉很多細(xì)節(jié)，只需要關(guān)心開發(fā)需要關(guān)注的端口號(hào)，鏡像等等。

??

應(yīng)對(duì)挑戰(zhàn)一，在OAM中可以定義數(shù)據(jù)庫表達(dá)資源需要使用云資源，Workload中可以根據(jù)自己的需要定義不同的組件，包括基于虛擬機(jī)的應(yīng)用、或者老的Function應(yīng)用。組件是應(yīng)用開發(fā)者關(guān)心的。

??

Trait

如果只是組件，組合起來就可以構(gòu)建簡(jiǎn)單的應(yīng)用。如果關(guān)心應(yīng)用運(yùn)維的問題，OAM中有Trait的概念，指的是在原來組件的基礎(chǔ)上附加一些特征。特征指的是運(yùn)維的能力，如手動(dòng)擴(kuò)縮容能力、外部訪問能力、發(fā)布、負(fù)載均衡。彈性擴(kuò)縮容、基于流量的管理等等。通過OAM的Trait可以很靈活的得到插件化擴(kuò)充能力。不同的component綁定不同的特征。

??

Scope

Component，Trait以及所有組裝起來的Application Configuration就是OAM中的三種主要的概念。但當(dāng)多個(gè)組件共同協(xié)作時(shí)應(yīng)該如何處理?OAM中有個(gè)邊界Scope的概念，是一種特殊的Trait，將多個(gè)Component組合在一起，共享一組資源組，CPU等特征用Scope表示，拓展多個(gè)組件的共同特征。

??

四 OAM加持下的下一代DevOps技術(shù)

OAM：以應(yīng)用為中心的分層模型

OAM是以應(yīng)用為中心的分層模型，首先需要運(yùn)行在服務(wù)端的OAM解釋器，對(duì)于YAML的讀取需要通過OAM解釋器。OAM提供Trait，Component讓用戶填寫，編成APP Config。APP Config通過OAM解釋器具備Deployment，Ingress，HPA或者云資源等能力。這種方法可以將研發(fā)、運(yùn)維基于基礎(chǔ)設(shè)施進(jìn)行分層，研發(fā)關(guān)心Component，運(yùn)維關(guān)心Trait，基礎(chǔ)設(shè)施通過OAM解釋器提供各種能力，與K8s緊密結(jié)合，對(duì)其應(yīng)用概念做了補(bǔ)充。

??

• 分層
• 模塊化
• 可復(fù)用

快速的納入K8s生態(tài)已有Operater能力

OAM可以快速的納入K8s生態(tài)已有的Operater能力，下圖左邊的Component中是一個(gè)CRD的實(shí)例，右邊是Trait中的CRD的實(shí)例，中間表示Component底下的Workload和Trait分別對(duì)應(yīng)了K8s自定義資源的能力。如果想要使用K8s中的某些能力，只需要在Trait中寫入相應(yīng)的字段即可。

??

OAM框架解決組件依賴關(guān)系和啟動(dòng)順序

OAM框架解決組件依賴關(guān)系和啟動(dòng)順序。OAM Runtime，OAM解釋器會(huì)將組件依賴關(guān)系和啟動(dòng)順序處理好，下圖中Component之間有dependency關(guān)系，Trait與Component之間有preComponent或者postComponent等關(guān)系。

??

OAM Trait靈活解決資源綁定難題

啟動(dòng)順序厘清之后涉及到資源綁定問題，一邊是使用的數(shù)據(jù)庫，另一邊是Web的程序，Web的程序綁定數(shù)據(jù)庫連接串資源。在OAM中只需要寫一個(gè)Trait就可以解決資源綁定問題，下圖右邊，K8s通過Secret承載連接串信息，Service Binding Trait對(duì)應(yīng)一個(gè)運(yùn)行的Operator，Web Hook拿到Secret后注入進(jìn)數(shù)據(jù)庫中。

??

Workload與Trait交互機(jī)制

大家會(huì)考慮接入OAM會(huì)不會(huì)比較麻煩，需不需要改代碼。OAM設(shè)計(jì)了Workload與Trait交互機(jī)制，OAM內(nèi)部零改造，只需要擴(kuò)展Workload和Trait。首先，Component中創(chuàng)建Workload實(shí)例，再創(chuàng)建Trait實(shí)例，只需要在Trait中查看Workload的Definition，從而配置Trait中需要的能力。

??

OAM內(nèi)核零改造，插件式快速接入新能力

如果開發(fā)了新的能力，碰到?jīng)_突問題也是非常頭痛的。在OAM框架中定義Trait時(shí)，可以檢查哪些字段是沖突的，拒絕掉新的應(yīng)用的創(chuàng)建，從而保障Trait之間的兼容性，使得運(yùn)維問題可發(fā)現(xiàn)、可管理。

??

可發(fā)現(xiàn)、可管理的 Traits 系統(tǒng)

OAM：無限能力的DevOps平臺(tái)體系

下圖是DevOps平臺(tái)體系，最下層是OAM Runtime，一部分是Workload，對(duì)應(yīng)運(yùn)行時(shí)的承載的Runtime，如Function、Container、虛擬機(jī)、Serverless Service等。另一部分是Trait，對(duì)應(yīng)運(yùn)維能力，如發(fā)布、彈性擴(kuò)縮容、日志、安全等等。再上一層可以根據(jù)場(chǎng)景化組合(Application Profile)組裝成不同的業(yè)務(wù)形態(tài)平臺(tái)，不同平臺(tái)可以使用不同組合的Workload和Trait，具備不同的能力。通過OAM標(biāo)準(zhǔn)化的模型構(gòu)建無限能力的DevOps平臺(tái)，滿足各種場(chǎng)景的需要。

??

在用戶側(cè)，OAM加持下的研發(fā)DevOps流程在鏡像構(gòu)建完成之后使用達(dá)到統(tǒng)一，OAM提供了APP Config，包含不同的Component，每個(gè)Component包含不同的運(yùn)維能力Trait，支持不同的環(huán)境，如測(cè)試環(huán)境、生成環(huán)境。OAM配置統(tǒng)一，適合不同的云，可以拿到不同的集群中直接運(yùn)行。在K8s側(cè)，用戶只需要裝上插件，就可以很方便的嵌入很多豐富的能力。

??

【本文為51CTO專欄作者“阿里巴巴官方技術(shù)”原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】

??戳這里，看該作者更多好文??