本篇文章為大家展示了Kubernetes實踐中OAM應(yīng)用為中心的解決方案，內(nèi)容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。
成都創(chuàng)新互聯(lián)公司成立于2013年，先為凌海等服務(wù)建站，凌海等地企業(yè)，進行企業(yè)商務(wù)咨詢服務(wù)。為凌海企業(yè)網(wǎng)站制作PC+手機+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。
OAM 模型的價值
針對上述用戶的訴求，我們一個個來看 OAM 是如何滿足的，同時也能看出 OAM 在其中發(fā)揮的價值。
OAM 應(yīng)用定義是聲明式的，即面向終態(tài)的，它的格式與 K8s 的 API 一致，可以與 K8s 的 CRD 無縫對接，直接作為 Custom Resource 的 Object 部署到 K8s；
OAM 應(yīng)用定義是自包含的，通過 OAM 定義的描述可以找到包含一個應(yīng)用生命周期中方方面面所有的信息。
如下圖所示，你可以看到運行 OAM 的一個應(yīng)用配置，使用 K8s 的 API spec，完整包含了一個應(yīng)用方方面面的資源。
OAM 應(yīng)用定義并不限定你底層的平臺和實際運行時，你完全可以運行在 K8s 以外的平臺，不管是 ECS、Docker、又或是 FaaS (Serverless)，自然也不存在廠商鎖定的問題。如果你的應(yīng)用滿足 Serverless 的條件，那么針對該應(yīng)用的 OAM 描述，天然就可以運行在支持 OAM 規(guī)范的 Serverless 運行時。
在支持 OAM 的不同環(huán)境中，你便可以使用統(tǒng)一的應(yīng)用描述，打造無差別的應(yīng)用交付。就如下圖所示，對應(yīng)用戶，他們只要描述統(tǒng)一的應(yīng)用配置，便可以在不同的環(huán)境達到一致的應(yīng)用體驗。
OAM(Open Application Model) 正是這樣一個以應(yīng)用為中心的 K8s API 分層模型：
從研發(fā)的角度，他操作和關(guān)注的 API 對象叫 Component；
從運維的角度，模塊化的運維能力封裝就是 Trait，而運維可以通過 App Config 將 Component 和 Trait 自由組合，最終實例化成一個運行的應(yīng)用；
K8s 團隊本身則仍然基于 K8s 的原生 API 迭代這一層能力。
針對研發(fā)時常抱怨的 K8s API 太復(fù)雜，我們通過關(guān)注點分離，區(qū)分使用者面對的 API 來解決，同時提供了幾種核心的 Workload，讓研發(fā)只需要填寫少數(shù)幾個字段就可以完成組件的定義；針對復(fù)雜應(yīng)用定義，我們通過擴展的 Workload，允許研發(fā)對接 CRD Operator 的方式對接自定義 Workload。
針對運維需要的模塊化封裝運維能力和全局管理的需求，OAM 模型通過 Trait 來提供。
Trait 是運維能力的體現(xiàn)，不同的 Trait 也對應(yīng)了不同類型的運維能力，如日志收集 Trait、負載均衡 Trait、水平擴縮容 Trait 等等；同時 OAM 本身就提供了一個全局管理的標準，OAM 模型的實現(xiàn)層可以輕松針對 OAM 定義里的種種 Trait 描述進行管理和檢查。
針對云資源，OAM 向上也提供了統(tǒng)一的 API，也是通過關(guān)注點分為三類：
一類是研發(fā)關(guān)注的云資源，如數(shù)據(jù)庫 RDS、對象存儲 OSS 等，通過擴展 Workload 接入；
另一類是運維關(guān)注的云資源，如負載均衡 SLB 等，通過 Trait 接入；
最后一類也是運維關(guān)注的云資源，但是可能包含多個應(yīng)用之間的聯(lián)動關(guān)系，如虛擬專有網(wǎng)絡(luò) VPC 等，通過應(yīng)用的 Scope 接入。Scope 則是 OAM 中管理多應(yīng)用聯(lián)動關(guān)系的概念。
可以看到，OAM 通過統(tǒng)一的一套標準，解決了我們今天提到的所有難題。讓我們繼續(xù)深入到 OAM 中看看不同的概念具體是什么。
上述內(nèi)容就是Kubernetes實踐中OAM應(yīng)用為中心的解決方案，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。
重慶分公司
重慶分公司
