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