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

做者 | 孫健波（天元）

導讀：當前雲原生 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 生態基礎功能，包括鏡像託管、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 打包應用。打包好的應用部署到各個環境中。但整個過程當中會面臨不少挑戰。首先，在不一樣的環境須要不一樣的運維能力。

（一個雲原生 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 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的公衆號。」