如何基于K8s構建下一代DevOps平臺？
OAM是阿里巴巴與微軟聯(lián)合推出的開放應用模型，旨在解耦應用研發(fā)、應用運維與基礎設施人員在應用生命周期中各自的關注點，明晰責任與界限，聚焦自身業(yè)務，同時又依然能緊密協(xié)作。當前云原生DevOps體系現(xiàn)狀如何?面臨哪些挑戰(zhàn)?如何通過OAM解決云原生DevOps場景下的諸多問題?云原生開發(fā)應用模型OAM(Open Application Model)社區(qū)核心成員孫健波將為大家一一解答，并分享如何基于OAM和Kubernetes打造無限能力的下一代DevOps平臺。
一 什么是DevOps?為什么基于Kubernetes構建?
2009年舉辦了第一屆DevOpsDays大會，DevOps名字被首次提出。到2010年，DevOps的概念越來越火，出了What is DevOps的文章，講解了DevOps的概念，方法論及配套的工具。簡單來說，研發(fā)工程師需要和運維工程師深度的合作，同時通過一系列工具保證研發(fā)更加順暢，從而更容易的接觸生產環(huán)境。到2013年，Docker出現(xiàn)了，工程師可以第一次到軟件生產環(huán)境中定義，通過Docker image完成單機軟件的交付和分發(fā)。此時DevOps開始慢慢落地。2015年開始，DevOps相關的工具越來越多，資源利用率出現(xiàn)了一些問題，CNCF的成立使得DevOps的實踐往Kubernetes上走。
?? 
DevOps的三個階段
阿里在Kubernetes上的實踐也取得了非常好的成果。在規(guī)模方面，阿里內部集成了數(shù)十個節(jié)點可以達到上萬的集群，同時具備高性能和安全特性，秒級擴容，神龍+安全容器。具備極致的彈性，分鐘級拆解公有云計算資源，無限資源池。另一方面，Kubernetes社區(qū)已經(jīng)具備非常豐富的DevOps生態(tài)基礎功能，包括鏡像托管、CI\CD流水線、任務編排、發(fā)布策略、鏡像打包、分發(fā)、豐富的應用運行時的負載支撐、豐富彈性和應用擴容能力。
為什么阿里基于Kubernetes構建DevOps平臺?
1)阿里基于Kubernetes的無限資源池與基礎設施能力
- 大規(guī)模 – 單集群最高可達10000節(jié)點、百萬Pod
- 高性能 – 秒級擴容，智能伸縮，神龍 + 安全容器
- 極致彈性 – 分鐘級拆解公有云計算資源，無限資源池
2)社區(qū)圍繞Kubernetes已經(jīng)具備豐富的DevOps生態(tài)基礎功能
- 源碼到容器鏡像倉庫，Kubernetes是容器平臺事實標準：Github/DockerHub
- CI/CD流水線、任務編排、發(fā)布策略：Argo/Teckton/Spinnaker/Jenkins-X/Flagger
- 鏡像打包、分發(fā)：Helm/CNAB
- 豐富的應用運行負載支撐：Deployment(無狀態(tài))/StatefulSet(有狀態(tài))/OpenKruise(原生有狀態(tài)增強)
- 豐富的彈性和應用擴縮容能力：HPA/KEDA
二 基于Kubernetes的DevOps平臺新挑戰(zhàn)
下圖展示了一個云原生下的DevOps流水線的典型流程。首先是代碼的開發(fā)，代碼托管到Github，再接入單元測試的工具Jenkins，此時基本研發(fā)已完成。再接著到鏡像的構建，涉及到配置、編排等。云原生中可以用HELM打包應用。打包好的應用部署到各個環(huán)境中。但整個過程中會面臨很多挑戰(zhàn)。首先，在不同的環(huán)境需要不同的運維能力。
?? 
一個云原生 DevOps 流水線的典型流程
其次，配置的過程中要創(chuàng)建云上數(shù)據(jù)庫，需要另外打開一個控制臺來創(chuàng)建數(shù)據(jù)庫。還需要配置負載均衡。在應用啟動以后還需要配置額外的功能，包括日志、策略、安全防護等等?？梢园l(fā)現(xiàn)，云資源和DevOps平臺體驗是割裂的，里面充斥著借助外部平臺創(chuàng)建的過程。這對新手來說是非常痛苦的。
挑戰(zhàn)一：云資源與 DevOps 平臺體驗割裂
DevOps流程中充斥著大量需要外部平臺創(chuàng)建的過程：
?? 
挑戰(zhàn)二：研發(fā)、運維、基礎設施關注點耦合
下圖是常用的K8s的YAML配置文件，大家經(jīng)常吐槽這個配置文件很復雜。簡單來說YAML配置文件可以分為三大塊，一塊是運維比較關心的配置，包括實例數(shù)，策略和發(fā)布。第二塊是研發(fā)關心的，涉及到鏡像、端口號等。第三塊是基礎設施工程師看得懂的，如調度策略等。K8s的配置文件中將方方面面的信息都耦合在一起，這對K8s工程師來說是非常適合的，但是對應用側的終端工程師而言，有很多不需要關心的配置指標。
?? 
- DevOps流程中缺乏對“應用”這個概念的描述
- K8s 的 YAML文件的定位并不是終端用戶
挑戰(zhàn)三：平臺的自定義封裝，簡單卻能力不足
DevOps平臺對K8s能力封裝抽象，只剩下5個Deployment的字段需要研發(fā)填寫。從用戶角度而言，這種設置非常好用簡單。但是針對稍微復雜的應用，涉及到應用狀態(tài)管理，健康檢查等等一系列的操作，此時這5個字段是不夠的。
?? 
挑戰(zhàn)四：CRD 擴展能力強大，DevOps 平臺無法直接復用
CRD(Customize Resource Definition)擴展能力強大，幾乎所有軟件都可以通過CRD的方式進行擴展，包括數(shù)據(jù)庫、存儲、安全、編排、依賴管理、發(fā)布等。但是對DevOps平臺來說，上面接口并沒有向用戶暴露，導致無法直接復用。
?? 
挑戰(zhàn)五：DevOps 平臺開發(fā)的新能力使用門檻高
如果平臺想要擴展一些能力，而原生的自動擴縮容能力不太合適，希望開發(fā)定時的擴縮容YAML文件，隨著業(yè)務情況而設置。但此時用戶使用YAML的門檻非常高，不清楚如何使用YAML。隨著新能力開發(fā)越來越多，能力之間會出現(xiàn)沖突，這也非常難以管理。
?? 
CronHPA
- 運維同學怎么知道這個擴展能力怎么用?
- 看 CRD?看配置文件?看 …… 文檔?
- 擴展能力間出現(xiàn)沖突，導致線上故障
- 比如：CronHPA 和 默認 HPA 被同時安裝給了同一個應用
- K8s 擴展能力之間的沖突關系，如何有效管理?如何有效的對運維透出?
挑戰(zhàn)六：不同 DevOps 平臺需要完全重新對接
很多云原生實踐中會遇到的問題，即需要定義非常復雜的YAML，這種方式可以解決企業(yè)內部所有問題，但是挑戰(zhàn)在于很難與生態(tài)進行對接。如RDS，SLB的能力都嵌到YAML文件中，無法復用，幾乎不具備原子化能力。同時無法協(xié)作，無法提供給兄弟部門或生態(tài)使用，只能給內部封閉生態(tài)使用。上層系統(tǒng)不同應用對接DevOps平臺時，需要寫不同格式的YAML，這也是非常痛苦的。
?? 
- 難以理解，必須通過界面可視化透出
- 無法復用，幾乎不具備原子化能力
- 無法協(xié)作，只能內部封閉生態(tài)使用
三 OAM應用模型的技術原理
Component組件
OAM中常見的概念是Component組件，完全從研發(fā)角度定義的待部署單元。下圖右側是YAML中Component的例子，其中黃色部分可以靈活自定義。OAM中會定義標準的架構ContaineriseWorkload，表示工作負載部分，里面是待部署單元的具體描述。這時就可以解決關注點分離的問題，幫助應用側工程師去掉很多細節(jié)，只需要關心開發(fā)需要關注的端口號，鏡像等等。
?? 
應對挑戰(zhàn)一，在OAM中可以定義數(shù)據(jù)庫表達資源需要使用云資源，Workload中可以根據(jù)自己的需要定義不同的組件，包括基于虛擬機的應用、或者老的Function應用。組件是應用開發(fā)者關心的。
?? 
Trait
如果只是組件，組合起來就可以構建簡單的應用。如果關心應用運維的問題，OAM中有Trait的概念，指的是在原來組件的基礎上附加一些特征。特征指的是運維的能力，如手動擴縮容能力、外部訪問能力、發(fā)布、負載均衡。彈性擴縮容、基于流量的管理等等。通過OAM的Trait可以很靈活的得到插件化擴充能力。不同的component綁定不同的特征。
?? 
Scope
Component，Trait以及所有組裝起來的Application Configuration就是OAM中的三種主要的概念。但當多個組件共同協(xié)作時應該如何處理?OAM中有個邊界Scope的概念，是一種特殊的Trait，將多個Component組合在一起，共享一組資源組，CPU等特征用Scope表示，拓展多個組件的共同特征。
?? 
四 OAM加持下的下一代DevOps技術
OAM：以應用為中心的分層模型
OAM是以應用為中心的分層模型，首先需要運行在服務端的OAM解釋器，對于YAML的讀取需要通過OAM解釋器。OAM提供Trait，Component讓用戶填寫，編成APP Config。APP Config通過OAM解釋器具備Deployment，Ingress，HPA或者云資源等能力。這種方法可以將研發(fā)、運維基于基礎設施進行分層，研發(fā)關心Component，運維關心Trait，基礎設施通過OAM解釋器提供各種能力，與K8s緊密結合，對其應用概念做了補充。
?? 
- 分層
- 模塊化
- 可復用
快速的納入K8s生態(tài)已有Operater能力
OAM可以快速的納入K8s生態(tài)已有的Operater能力，下圖左邊的Component中是一個CRD的實例，右邊是Trait中的CRD的實例，中間表示Component底下的Workload和Trait分別對應了K8s自定義資源的能力。如果想要使用K8s中的某些能力，只需要在Trait中寫入相應的字段即可。
?? 
OAM框架解決組件依賴關系和啟動順序
OAM框架解決組件依賴關系和啟動順序。OAM Runtime，OAM解釋器會將組件依賴關系和啟動順序處理好，下圖中Component之間有dependency關系，Trait與Component之間有preComponent或者postComponent等關系。
?? 
OAM Trait靈活解決資源綁定難題
啟動順序厘清之后涉及到資源綁定問題，一邊是使用的數(shù)據(jù)庫，另一邊是Web的程序，Web的程序綁定數(shù)據(jù)庫連接串資源。在OAM中只需要寫一個Trait就可以解決資源綁定問題，下圖右邊，K8s通過Secret承載連接串信息，Service Binding Trait對應一個運行的Operator，Web Hook拿到Secret后注入進數(shù)據(jù)庫中。
?? 
Workload與Trait交互機制
大家會考慮接入OAM會不會比較麻煩，需不需要改代碼。OAM設計了Workload與Trait交互機制，OAM內部零改造，只需要擴展Workload和Trait。首先，Component中創(chuàng)建Workload實例，再創(chuàng)建Trait實例，只需要在Trait中查看Workload的Definition，從而配置Trait中需要的能力。
?? 
OAM內核零改造，插件式快速接入新能力
如果開發(fā)了新的能力，碰到?jīng)_突問題也是非常頭痛的。在OAM框架中定義Trait時，可以檢查哪些字段是沖突的，拒絕掉新的應用的創(chuàng)建，從而保障Trait之間的兼容性，使得運維問題可發(fā)現(xiàn)、可管理。
?? 
可發(fā)現(xiàn)、可管理的 Traits 系統(tǒng)
OAM：無限能力的DevOps平臺體系
下圖是DevOps平臺體系，最下層是OAM Runtime，一部分是Workload，對應運行時的承載的Runtime，如Function、Container、虛擬機、Serverless Service等。另一部分是Trait，對應運維能力，如發(fā)布、彈性擴縮容、日志、安全等等。再上一層可以根據(jù)場景化組合(Application Profile)組裝成不同的業(yè)務形態(tài)平臺，不同平臺可以使用不同組合的Workload和Trait，具備不同的能力。通過OAM標準化的模型構建無限能力的DevOps平臺，滿足各種場景的需要。
?? 
在用戶側，OAM加持下的研發(fā)DevOps流程在鏡像構建完成之后使用達到統(tǒng)一，OAM提供了APP Config，包含不同的Component，每個Component包含不同的運維能力Trait，支持不同的環(huán)境，如測試環(huán)境、生成環(huán)境。OAM配置統(tǒng)一，適合不同的云，可以拿到不同的集群中直接運行。在K8s側，用戶只需要裝上插件，就可以很方便的嵌入很多豐富的能力。
?? 
【本文為51CTO專欄作者“阿里巴巴官方技術”原創(chuàng)稿件，轉載請聯(lián)系原作者】
