如何基于K8s 構(gòu)建下一代DevOps 平臺

如何基于K8s 構(gòu)建下一代DevOps 平臺，針對這個問題，這篇文章詳細介紹了相對應(yīng)的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

導讀：當前云原生 DevOps 體系現(xiàn)狀如何？面臨哪些挑戰(zhàn)？下面如何通過 OAM 解決云原生 DevOps 場景下的諸多問題，并分享如何基于 OAM 和 Kubernetes 打造無限能力的下一代 DevOps 平臺。

什么是 DevOps？為什么基于 Kubernetes 構(gòu)建？

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

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

為什么基于 Kubernetes 構(gòu)建 DevOps平臺？

1）基于 Kubernetes 的無限資源池與基礎(chǔ)設(shè)施能力

• 大規(guī)模 – 單集群最高可達 10000 節(jié)點、百萬 Pod

• 高性能 – 秒級擴容，智能伸縮，神龍 + 安全容器

• 極致彈性 – 分鐘級拆解公有云計算資源，無限資源池

2）社區(qū)圍繞 Kubernetes 已經(jīng)具備豐富的 DevOps 生態(tài)基礎(chǔ)功能

• 源碼到容器鏡像倉庫，Kubernetes 是容器平臺事實標準：Github / DockerHub；

• CI/CD 流水線、任務(wù)編排、發(fā)布策略：Argo / Teckton / Spinnaker / Jenkins-X / Flagger；

• 鏡像打包、分發(fā)：Helm / CNAB；

• 豐富的應(yīng)用運行負載支撐：Deployment(無狀態(tài)) / StatefulSet(有狀態(tài)) / OpenKruise(原生有狀態(tài)增強)；

• 豐富的彈性和應(yīng)用擴縮容能力：HPA / KEDA。

基于 Kubernetes 的 DevOps 平臺新挑戰(zhàn)

下圖展示了一個云原生下的 DevOps 流水線的典型流程。首先是代碼的開發(fā)，代碼托管到 Github，再接入單元測試的工具 Jenkins，此時基本研發(fā)已完成。再接著到鏡像的構(gòu)建，涉及到配置、編排等。云原生中可以用 HELM 打包應(yīng)用。打包好的應(yīng)用部署到各個環(huán)境中。但整個過程中會面臨很多挑戰(zhàn)。首先，在不同的環(huán)境需要不同的運維能力。

（一個云原生 DevOps 流水線的典型流程）

其次，配置的過程中要創(chuàng)建云上數(shù)據(jù)庫，需要另外打開一個控制臺來創(chuàng)建數(shù)據(jù)庫。還需要配置負載均衡。在應(yīng)用啟動以后還需要配置額外的功能，包括日志、策略、安全防護等等?？梢园l(fā)現(xiàn)，云資源和 DevOps 平臺體驗是割裂的，里面充斥著借助外部平臺創(chuàng)建的過程。這對新手來說是非常痛苦的。

挑戰(zhàn)一：研發(fā)、運維、基礎(chǔ)設(shè)施關(guān)注點耦合

下圖是常用的 K8s 的 YAML 配置文件，大家經(jīng)常吐槽這個配置文件很復(fù)雜。

簡單來說 YAML 配置文件可以分為三大塊，一塊是運維比較關(guān)心的配置，包括實例數(shù)，策略和發(fā)布。第二塊是研發(fā)關(guān)心的，涉及到鏡像、端口號等。第三塊是基礎(chǔ)設(shè)施工程師看得懂的，如調(diào)度策略等。K8s 的配置文件中將方方面面的信息都耦合在一起，這對 K8s 工程師來說是非常適合的，但是對應(yīng)用側(cè)的終端工程師而言，有很多不需要關(guān)心的配置指標。

• DevOps 流程中缺乏對“應(yīng)用”這個概念的描述

• K8s 的 YAML 文件的定位并不是終端用戶

挑戰(zhàn)二：平臺的自定義封裝，簡單卻能力不足

DevOps 平臺對 K8s 能力封裝抽象，只剩下 5 個 Deployment 的字段需要研發(fā)填寫。從用戶角度而言，這種設(shè)置非常好用簡單。但是針對稍微復(fù)雜的應(yīng)用，涉及到應(yīng)用狀態(tài)管理，健康檢查等等一系列的操作，此時這 5 個字段是不夠的。

挑戰(zhàn)三：CRD 擴展能力強大，DevOps 平臺無法直接復(fù)用

CRD(Customize Resource Definition) 擴展能力強大，幾乎所有軟件都可以通過 CRD 的方式進行擴展，包括數(shù)據(jù)庫、存儲、安全、編排、依賴管理、發(fā)布等。但是對 DevOps 平臺來說，上面接口并沒有向用戶暴露，導致無法直接復(fù)用。

挑戰(zhàn)四：DevOps 平臺開發(fā)的新能力使用門檻高

如果平臺想要擴展一些能力，而原生的自動擴縮容能力不太合適，希望開發(fā)定時的擴縮容YAML文件，隨著業(yè)務(wù)情況而設(shè)置。但此時用戶使用YAML的門檻非常高，不清楚如何使用YAML。隨著新能力開發(fā)越來越多，能力之間會出現(xiàn)沖突，這也非常難以管理。

運維同學怎么知道這個擴展能力怎么用？看 CRD？看配置文件？看 …… 文檔？

擴展能力間出現(xiàn)沖突，導致線上故障，比如：CronHPA 和 默認 HPA 被同時安裝給了同一個應(yīng)用；K8s 擴展能力之間的沖突關(guān)系，如何有效管理？如何有效的對運維透出？

挑戰(zhàn)五：不同 DevOps 平臺需要完全重新對接

很多云原生實踐中會遇到的問題，即需要定義非常復(fù)雜的 YAML，這種方式可以解決企業(yè)內(nèi)部所有問題，但是挑戰(zhàn)在于很難與生態(tài)進行對接。如 RDS，SLB 的能力都嵌到 YAML 文件中，無法復(fù)用，幾乎不具備原子化能力。同時無法協(xié)作，無法提供給兄弟部門或生態(tài)使用，只能給內(nèi)部封閉生態(tài)使用。上層系統(tǒng)不同應(yīng)用對接 DevOps 平臺時，需要寫不同格式的 YAML，這也是非常痛苦的。

• 難以理解，必須通過界面可視化透出

• 無法復(fù)用，幾乎不具備原子化能力

• 無法協(xié)作，只能內(nèi)部封閉生態(tài)使用

OAM 應(yīng)用模型的技術(shù)原理

OAM 應(yīng)用模型的出現(xiàn)，解決了上述應(yīng)用管理的難題，下面我們來介紹一下 OAM 模型的技術(shù)原理。

1. Component 組件

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

應(yīng)對挑戰(zhàn)一，在 OAM 中可以定義數(shù)據(jù)庫表達資源需要使用云資源，Workload 中可以根據(jù)自己的需要定義不同的組件，包括基于虛擬機的應(yīng)用、或者老的 Function 應(yīng)用。組件是應(yīng)用開發(fā)者關(guān)心的。

2. Trait

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

3. Scope

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

OAM 加持下的下一代 DevOps 技術(shù)

1. OAM：以應(yīng)用為中心的分層模型

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

• 分層

• 模塊化

• 可復(fù)用

2. 快速的納入 K8s 生態(tài)已有 Operater 能力

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

3. OAM 框架解決組件依賴關(guān)系和啟動順序

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

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

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

5. Workload 與 Trait 交互機制

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

（OAM 內(nèi)核零改造，插件式快速接入新能力）

如果開發(fā)了新的能力，碰到?jīng)_突問題也是非常頭痛的。在 OAM 框架中定義 Trait 時，可以檢查哪些字段是沖突的，拒絕掉新的應(yīng)用的創(chuàng)建，從而保障 Trait 之間的兼容性，使得運維問題可發(fā)現(xiàn)、可管理。

（可發(fā)現(xiàn)、可管理的 Traits 系統(tǒng)）

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

下圖是 DevOps 平臺體系，最下層是 OAM Runtime，一部分是 Workload，對應(yīng)運行時的承載的 Runtime，如 Function、Container、虛擬機、Serverless Service 等。另一部分是 Trait，對應(yīng)運維能力，如發(fā)布、彈性擴縮容、日志、安全等等。再上一層可以根據(jù)場景化組合（Application Profile）組裝成不同的業(yè)務(wù)形態(tài)平臺，不同平臺可以使用不同組合的 Workload 和 Trait，具備不同的能力。通過 OAM 標準化的模型構(gòu)建無限能力的 DevOps 平臺，滿足各種場景的需要。

在用戶側(cè)，OAM 加持下的研發(fā) DevOps 流程在鏡像構(gòu)建完成之后使用達到統(tǒng)一，OAM 提供了 APP Config，包含不同的 Component，每個 Component 包含不同的運維能力 Trait，支持不同的環(huán)境，如測試環(huán)境、生成環(huán)境。OAM 配置統(tǒng)一，適合不同的云，可以拿到不同的集群中直接運行。在 K8s 側(cè)，用戶只需要裝上插件，就可以很方便的嵌入很多豐富的能力。

關(guān)于如何基于K8s 構(gòu)建下一代DevOps 平臺問題的解答就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注億速云行業(yè)資訊頻道了解更多相關(guān)知識。