Kubernetes實踐中OAM應用為中心的解決方案

本篇文章為大家展示了Kubernetes實踐中OAM應用為中心的解決方案，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

OAM 模型的價值

針對上述用戶的訴求，我們一個個來看 OAM 是如何滿足的，同時也能看出 OAM 在其中發揮的價值。

云原生化

• OAM 應用定義是聲明式的，即面向終態的，它的格式與 K8s 的 API 一致，可以與 K8s 的 CRD 無縫對接，直接作為 Custom Resource 的 Object 部署到 K8s；

• OAM 應用定義是自包含的，通過 OAM 定義的描述可以找到包含一個應用生命周期中方方面面所有的信息。

如下圖所示，你可以看到運行 OAM 的一個應用配置，使用 K8s 的 API spec，完整包含了一個應用方方面面的資源。

平臺無關、運行時無關

OAM 應用定義并不限定你底層的平臺和實際運行時，你完全可以運行在 K8s 以外的平臺，不管是 ECS、Docker、又或是 FaaS (Serverless)，自然也不存在廠商鎖定的問題。如果你的應用滿足 Serverless 的條件，那么針對該應用的 OAM 描述，天然就可以運行在支持 OAM 規范的 Serverless 運行時。

在支持 OAM 的不同環境中，你便可以使用統一的應用描述，打造無差別的應用交付。就如下圖所示，對應用戶，他們只要描述統一的應用配置，便可以在不同的環境達到一致的應用體驗。

OAM(Open Application Model) 正是這樣一個以應用為中心的 K8s API 分層模型：

• 從研發的角度，他操作和關注的 API 對象叫 Component；

• 從運維的角度，模塊化的運維能力封裝就是 Trait，而運維可以通過 App Config 將 Component 和 Trait 自由組合，最終實例化成一個運行的應用；

• K8s 團隊本身則仍然基于 K8s 的原生 API 迭代這一層能力。

針對研發時常抱怨的 K8s API 太復雜，我們通過關注點分離，區分使用者面對的 API 來解決，同時提供了幾種核心的 Workload，讓研發只需要填寫少數幾個字段就可以完成組件的定義；針對復雜應用定義，我們通過擴展的 Workload，允許研發對接 CRD Operator 的方式對接自定義 Workload。

針對運維需要的模塊化封裝運維能力和全局管理的需求，OAM 模型通過 Trait 來提供。

Trait 是運維能力的體現，不同的 Trait 也對應了不同類型的運維能力，如日志收集 Trait、負載均衡 Trait、水平擴縮容 Trait 等等；同時 OAM 本身就提供了一個全局管理的標準，OAM 模型的實現層可以輕松針對 OAM 定義里的種種 Trait 描述進行管理和檢查。

針對云資源，OAM 向上也提供了統一的 API，也是通過關注點分為三類：

• 一類是研發關注的云資源，如數據庫 RDS、對象存儲 OSS 等，通過擴展 Workload 接入；

• 另一類是運維關注的云資源，如負載均衡 SLB 等，通過 Trait 接入；

• 最后一類也是運維關注的云資源，但是可能包含多個應用之間的聯動關系，如虛擬專有網絡 VPC 等，通過應用的 Scope 接入。Scope 則是 OAM 中管理多應用聯動關系的概念。

可以看到，OAM 通過統一的一套標準，解決了我們今天提到的所有難題。讓我們繼續深入到 OAM 中看看不同的概念具體是什么。

上述內容就是Kubernetes實踐中OAM應用為中心的解決方案，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。