作者 | 孫健波（天元）

導讀：當前雲原生 DevOps 體系現狀如何？面臨哪些挑戰？如何通過 OAM 解決雲原生 DevOps 場景下的諸多問題？雲原生開發應用模型 OAM(Open Application Model) 社區核心成員孫健波將為大家一一解答，並分享如何基於 OAM 和 Kubernetes 打造無限能力的下一代 DevOps 平臺。

什麼是 DevOps？為什麼基於 Kubernetes 構建？

2009 年舉辦了第一屆 DevOpsDays 大會，DevOps 名字被首次提出。到 2010 年，DevOps 的概念越來越火，出了 What is DevOps 的文章，講解了 DevOps 的概念，方法論及配套的工具。簡單來說，研發工程師需要和運維工程師深度的合作，同時通過一系列工具保證研發更加順暢，從而更容易的接觸生產環境。

到 2013 年，Docker 出現了，工程師可以第一次到軟件生產環境中定義，通過 Docker image 完成單機軟件的交付和分發。此時 DevOps 開始慢慢落地。2015 年開始，DevOps 相關的工具越來越多，資源利用率出現了一些問題，CNCF 的成立使得 DevOps 的實踐往 Kubernetes 上走。

（DevOps 的三個階段）

阿里在 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 平臺體驗割裂

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 應用模型的技術原理

OAM 應用模型的出現，解決了上述應用管理的難題，下面我們來介紹一下 OAM 模型的技術原理。

1. Component 組件

OAM 中常見的概念是 Component 組件，完全從研發角度定義的待部署單元。下圖右側是 YAML 中 Component 的例子，其中黃色部分可以靈活自定義。OAM 中會定義標準的架構 ContaineriseWorkload，表示工作負載部分，裡面是待部署單元的具體描述。這時就可以解決關注點分離的問題，幫助應用側工程師去掉很多細節，只需要關心開發需要關注的端口號，鏡像等等。

應對挑戰一，在 OAM 中可以定義數據庫表達資源需要使用雲資源，Workload 中可以根據自己的需要定義不同的組件，包括基於虛擬機的應用、或者老的 Function 應用。組件是應用開發者關心的。

2. Trait

如果只是組件，組合起來就可以構建簡單的應用。如果關心應用運維的問題，OAM 中有 Trait 的概念，指的是在原來組件的基礎上附加一些特徵。特徵指的是運維的能力，如手動擴縮容能力、外部訪問能力、發佈、負載均衡。彈性擴縮容、基於流量的管理等等。通過 OAM 的 Trait 可以很靈活的得到插件化擴充能力。不同的 component 綁定不同的特徵。

3. Scope

Component，Trait 以及所有組裝起來的 Application Configuration 就是 OAM 中的三種主要的概念。但當多個組件共同協作時應該如何處理？OAM 中有個邊界 Scope 的概念，是一種特殊的 Trait，將多個 Component 組合在一起，共享一組資源組，CPU 等特徵用 Scope 表示，拓展多個組件的共同特徵。

OAM 加持下的下一代 DevOps 技術

1. OAM：以應用為中心的分層模型

OAM 是以應用為中心的分層模型，首先需要運行在服務端的 OAM 解釋器，對於 YAML 的讀取需要通過 OAM 解釋器。OAM 提供 Trait，Component 讓用戶填寫，編成 APP Config。APP Config 通過 OAM 解釋器具備 Deployment，Ingress，HPA 或者雲資源等能力。這種方法可以將研發、運維基於基礎設施進行分層，研發關心 Component，運維關心 Trait，基礎設施通過 OAM 解釋器提供各種能力，與 K8s 緊密結合，對其應用概念做了補充。

• 分層
• 模塊化
• 可複用

2. 快速的納入 K8s 生態已有 Operater 能力

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

3. OAM 框架解決組件依賴關係和啟動順序

OAM 框架解決組件依賴關係和啟動順序。OAM Runtime，OAM 解釋器會將組件依賴關係和啟動順序處理好，下圖中 Component 之間有 dependency 關係，Trait 與 Component 之間有 preComponent 或者 postComponent 等關係。

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

啟動順序釐清之後涉及到資源綁定問題，一邊是使用的數據庫，另一邊是 Web 的程序，Web 的程序綁定數據庫連接串資源。在 OAM 中只需要寫一個 Trait 就可以解決資源綁定問題，下圖右邊，K8s 通過 Secret 承載連接串信息，Service Binding Trait 對應一個運行的 Operator，Web Hook 拿到 Secret 後注入進數據庫中。

5. Workload 與 Trait 交互機制

大家會考慮接入 OAM 會不會比較麻煩，需不需要改代碼。OAM 設計了 Workload 與 Trait 交互機制，OAM 內部零改造，只需要擴展 Workload 和 Trait。首先，Component 中創建 Workload 實例，再創建 Trait 實例，只需要在 Trait 中查看 Workload 的 Definition，從而配置 Trait 中需要的能力。

（OAM 內核零改造，插件式快速接入新能力）

如果開發了新的能力，碰到衝突問題也是非常頭痛的。在 OAM 框架中定義 Trait 時，可以檢查哪些字段是衝突的，拒絕掉新的應用的創建，從而保障 Trait 之間的兼容性，使得運維問題可發現、可管理。

（可發現、可管理的 Traits 系統）

6. 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 側，用戶只需要裝上插件，就可以很方便的嵌入很多豐富的能力。

如果有其他問題，建議大家加入我們的釘釘群進行討論。（釘釘搜索群號：23310022，即可進群）

課程推薦

去年，CNCF 與 阿里雲聯合發佈了《雲原生技術公開課》已經成為了 Kubernetes 開發者的一門“必修課”。今天，阿里雲再次集結多位具有豐富雲原生實踐經驗的技術專家，正式推出《雲原生技術實踐公開課》。課程內容由淺入深，專注講解“ 落地實踐”。還為學習者打造了真實、可操作的實驗場景，方便驗證學習成果，也為之後的實踐應用打下堅實基礎。

點擊鏈接即可免費觀看：https://developer.aliyun.com/learning/roadmap/cloudnative2020

“阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”