作者 | 孫健波（天元）
導讀：目前雲原生 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 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公衆号。”