![1.png](https://ucc.alicdn.com/pic/developer-ecology/c87492bdcdef49cea0f870029f8b0423.png)

作者 | 孫健波（天元）

> **導讀**：當前雲原生 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 上走。

![2.png](https://ucc.alicdn.com/pic/developer-ecology/f508ecb969094848a2687d82c82d1356.png)
（DevOps 的三個階段）

阿里在 Kubernetes 上的實踐也取得了非常好的成果。在規模方面，阿里內部整合了數十個節點可以達到上萬的叢集，同時具備高效能和安全特性，秒級擴容，神龍+安全容器。具備極致的彈性，分鐘級拆解公有云計算資源，無限資源池。另一方面，Kubernetes 社群已經具備非常豐富的 DevOps 生態基礎功能，包括映象託管、CI\CD 流水線、任務編排、釋出策略、映象打包、分發、豐富的應用執行時的負載支撐、豐富彈性和應用擴容能力。

## 為什麼阿里基於 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 打包應用。打包好的應用部署到各個環境中。但整個過程中會面臨很多挑戰。首先，在不同的環境需要不同的運維能力。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/17508f4156dc40f2ac6fd0eb8491e390.png)
（一個雲原生 DevOps 流水線的典型流程）

其次，配置的過程中要建立雲上資料庫，需要另外開啟一個控制檯來建立資料庫。還需要配置負載均衡。在應用啟動以後還需要配置額外的功能，包括日誌、策略、安全防護等等。可以發現，雲資源和 DevOps 平臺體驗是割裂的，裡面充斥著藉助外部平臺建立的過程。這對新手來說是非常痛苦的。

## 挑戰一：雲資源與 DevOps 平臺體驗割裂

DevOps 流程中充斥著大量需要外部平臺建立的過程：

![4.png](https://ucc.alicdn.com/pic/developer-ecology/0a13ea6ff19b4219904c985b96b8f8da.png)

## 挑戰二：研發、運維、基礎設施關注點耦合

下圖是常用的 K8s 的 YAML 配置檔案，大家經常吐槽這個配置檔案很複雜。

簡單來說 YAML 配置檔案可以分為三大塊，一塊是運維比較關心的配置，包括例項數，策略和釋出。第二塊是研發關心的，涉及到映象、埠號等。第三塊是基礎設施工程師看得懂的，如排程策略等。K8s 的配置檔案中將方方面面的資訊都耦合在一起，這對 K8s 工程師來說是非常適合的，但是對應用側的終端工程師而言，有很多不需要關心的配置指標。

![5.png](https://ucc.alicdn.com/pic/developer-ecology/6b640ba8078d4c819dc4b37614cbcc8e.png)

- DevOps 流程中缺乏對“應用”這個概念的描述
- K8s 的 YAML 檔案的定位並不是終端使用者

## 挑戰三：平臺的自定義封裝，簡單卻能力不足

DevOps 平臺對 K8s 能力封裝抽象，只剩下 5 個 Deployment 的欄位需要研發填寫。從使用者角度而言，這種設定非常好用簡單。但是針對稍微複雜的應用，涉及到應用狀態管理，健康檢查等等一系列的操作，此時這 5 個欄位是不夠的。

![6.png](https://ucc.alicdn.com/pic/developer-ecology/850c1152f55c4fe7b8d7d9049643ca06.png)

## 挑戰四：CRD 擴充套件能力強大，DevOps 平臺無法直接複用

CRD(Customize Resource Definition) 擴充套件能力強大，幾乎所有軟體都可以透過 CRD 的方式進行擴充套件，包括資料庫、儲存、安全、編排、依賴管理、釋出等。但是對 DevOps 平臺來說，上面介面並沒有向使用者暴露，導致無法直接複用。

![7.png](https://ucc.alicdn.com/pic/developer-ecology/f5e48c334be44442890456787c79b521.png)

## 挑戰五：DevOps 平臺開發的新能力使用門檻高

如果平臺想要擴充套件一些能力，而原生的自動擴縮容能力不太合適，希望開發定時的擴縮容YAML檔案，隨著業務情況而設定。但此時使用者使用YAML的門檻非常高，不清楚如何使用YAML。隨著新能力開發越來越多，能力之間會出現衝突，這也非常難以管理。

![8.png](https://ucc.alicdn.com/pic/developer-ecology/578c44e97f454f7299b3cd7a22b2a943.png)

- 運維同學怎麼知道這個擴充套件能力怎麼用？看 CRD？看配置檔案？看 …… 文件？

- 擴充套件能力間出現衝突，導致線上故障，比如：CronHPA 和 預設 HPA 被同時安裝給了同一個應用；K8s 擴充套件能力之間的衝突關係，如何有效管理？如何有效的對運維透出？

## 挑戰六：不同 DevOps 平臺需要完全重新對接

很多雲原生實踐中會遇到的問題，即需要定義非常複雜的 YAML，這種方式可以解決企業內部所有問題，但是挑戰在於很難與生態進行對接。如 RDS，SLB 的能力都嵌到 YAML 檔案中，無法複用，幾乎不具備原子化能力。同時無法協作，無法提供給兄弟部門或生態使用，只能給內部封閉生態使用。上層系統不同應用對接 DevOps 平臺時，需要寫不同格式的 YAML，這也是非常痛苦的。

![9.png](https://ucc.alicdn.com/pic/developer-ecology/087dc03d5d7f463483f54ade18177a5d.png)

- 難以理解，必須透過介面視覺化透出
- 無法複用，幾乎不具備原子化能力
- 無法協作，只能內部封閉生態使用

# OAM 應用模型的技術原理

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

## 1. Component 元件

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

![10.png](https://ucc.alicdn.com/pic/developer-ecology/6a47cd8112f242818846c09b0a946fec.png)

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

![11.png](https://ucc.alicdn.com/pic/developer-ecology/602f296b2f80428d9583269bf2d4db87.png)

## 2. Trait

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

![12.png](https://ucc.alicdn.com/pic/developer-ecology/2334c069c6ff4dc18583948cae39def3.png)

## 3. Scope

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

![13.png](https://ucc.alicdn.com/pic/developer-ecology/df06f9e8528a4f61823a6dad194fff56.png)

# OAM 加持下的下一代 DevOps 技術

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

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

![14.png](https://ucc.alicdn.com/pic/developer-ecology/72bacb4e1a89456786464ce1524d1b2f.png)

- 分層
- 模組化
- 可複用

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

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

![15.png](https://ucc.alicdn.com/pic/developer-ecology/0e61ad341a48444aacb4943575a6c7bc.png)

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

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

![16.png](https://ucc.alicdn.com/pic/developer-ecology/accd6e1edd4942bbbb409d2fc66f4a59.png)

## 4. OAM Trait 靈活解決資源繫結難題

啟動順序釐清之後涉及到資源繫結問題，一邊是使用的資料庫，另一邊是 Web 的程式，Web 的程式繫結資料庫連線串資源。在 OAM 中只需要寫一個 Trait 就可以解決資源繫結問題，下圖右邊，K8s 透過 Secret 承載連線串資訊，Service Binding Trait 對應一個執行的 Operator，Web Hook 拿到 Secret 後注入進資料庫中。

![17.png](https://ucc.alicdn.com/pic/developer-ecology/8d4dc3ddac9d424698021c99b756bab9.png)

## 5. Workload 與 Trait 互動機制

大家會考慮接入 OAM 會不會比較麻煩，需不需要改程式碼。OAM 設計了 Workload 與 Trait 互動機制，OAM 內部零改造，只需要擴充套件 Workload 和 Trait。首先，Component 中建立 Workload 例項，再建立 Trait 例項，只需要在 Trait 中檢視 Workload 的 Definition，從而配置 Trait 中需要的能力。

![18.png](https://ucc.alicdn.com/pic/developer-ecology/b2c4de8bb11d4ecc86eb7c4b5ab70bf8.png)
（OAM 核心零改造，外掛式快速接入新能力）

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

![19.png](https://ucc.alicdn.com/pic/developer-ecology/85c1d1a41ef941d292a26f5f50b2fad5.png)
（可發現、可管理的 Traits 系統）

## 6. OAM：無限能力的 DevOps 平臺體系

下圖是 DevOps 平臺體系，最下層是 OAM Runtime，一部分是 Workload，對應執行時的承載的 Runtime，如 Function、Container、虛擬機器、Serverless Service 等。另一部分是 Trait，對應運維能力，如釋出、彈性擴縮容、日誌、安全等等。再上一層可以根據場景化組合（Application Profile）組裝成不同的業務形態平臺，不同平臺可以使用不同組合的 Workload 和 Trait，具備不同的能力。透過 OAM 標準化的模型構建無限能力的 DevOps 平臺，滿足各種場景的需要。

![20.png](https://ucc.alicdn.com/pic/developer-ecology/93644603cc85497ab9a7422f64e4e5b0.png)

在使用者側，OAM 加持下的研發 DevOps 流程在映象構建完成之後使用達到統一，OAM 提供了 APP Config，包含不同的 Component，每個 Component 包含不同的運維能力 Trait，支援不同的環境，如測試環境、生成環境。OAM 配置統一，適合不同的雲，可以拿到不同的叢集中直接執行。在 K8s 側，使用者只需要裝上外掛，就可以很方便的嵌入很多豐富的能力。

![21.png](https://ucc.alicdn.com/pic/developer-ecology/2ceff2a17f1847db9f4ad1d98d45c685.png)

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

## 課程推薦

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

點選連結即可免費觀看：[https://developer.aliyun.com/learning/roadmap/cloudnative2020](https://developer.aliyun.com/learning/roadmap/cloudnative2020)

> “[阿里巴巴雲原生](https://mp.weixin.qq.com/s/aXdbBJlUAQp6YPvZU3isSQ)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”

如何基於 K8s 構建下一代 DevOps 平臺？

相關文章