4 個概念,1 個動作,讓應用管理變得更簡單
阿新 • • 發佈:2020-06-24
作者:
劉洋(炎尋) EDAS-OAM 架構與開發負責人
鄧洪超 OAM spec maintainer
孫健波(天元) OAM spec maintainer
元件、運維特徵、應用邊界通過應用配置(Application Configuration)例項化,然後再通過 OAM 的實現層翻譯為真實的資源。
上圖有兩種應用邊界型別:Network 與 Health,有四個元件分佈在不同的應用邊界例項中:
原文連結 本文為雲棲社群原創內容,未經允許不得轉載。
隨著以 K8s 為主的雲原生基礎架構遍地生根,越來越多的團隊開始基於 K8s 搭建持續部署、自助式釋出體驗的應用管理平臺。然而,在 K8s 交付和管理應用方面,目前還缺乏一個統一的標準,這最終促使我們與微軟聯合推出了首個雲原生應用標準定義與架構模型 - OAM。本文作者將從基本概念以及各個模組的封裝設計與用法等角度出發來詳細解讀 OAM。OAM 主要有三個特點:
- 開發和運維關注點分離:開發者關注業務邏輯,運維人員關注運維能力,讓不同角色更專注於領域知識和能力;
- 平臺無關與高可擴充套件:應用定義與平臺實現解耦,應用描述支援跨平臺實現和可擴充套件性;
- 模組化應用部署和運維特徵:應用部署和運維能力可以描述成高層抽象模組,開發和運維可以自由組合和支援模組化實現。
角色分類
OAM 將應用相關的人員劃分為 3 個角色:- 應用開發:關注應用程式碼開發和執行配置,是應用程式碼的領域專家,應用開發完成後打包(比如映象)交給應用運維;
- 應用運維:關注配置和執行應用例項的生命週期,比如灰度釋出、監控、報警等操作,是應用運維專家;
- 平臺運維:關注應用執行平臺的能力和穩定性,是底層(比如 Kubernetes 運維/優化,OS 等)的領域專家。
核心概念
OAM 包含以下核心概念:服務元件(Component Schematics)
應用開發使用服務元件來宣告應用的屬性(配置項),運維人員定義這些屬性之後就能按照元件宣告得到執行的元件例項,元件宣告包含以下資訊:- 工作負載型別(Workload type):表明該元件執行時的工作負載依賴;
- 元資料(Metadata):面向元件使用者的一些描述性資訊;
- 資源需求(Resource requirements):元件執行的最小資源需求,比如最小記憶體,CPU 和檔案掛載需求;
- 引數(Parameters):可以被運維人員配置的引數;
- 工作負載定義(Workload definition):工作負載執行的一些定義,比如可執行包定義(ICO images,Function等)。
應用邊界(Application Scopes)
運維人員使用應用邊界將元件組成鬆耦合的應用,可以賦予這組元件一些共用的屬性和依賴,應用邊界宣告包含以下資訊:- 元資料(Metadata):面向應用邊界使用者的一些描述性資訊。
- 型別(Type):邊界型別,不同型別提供不同的能力;
- 引數(Parameters):可以被運維人員配置的引數。
運維特徵(Traits)
運維人員使用運維特徵賦予元件例項特定的運維能力,比如自動擴縮容,一個 Trait 可能僅限特定的工作負載型別,它們代表了系統運維方面的特性,而不是開發的特性,比如開發者知道自己的元件是否可以擴縮容,但是運維可以決定是手動擴縮容還是自動擴縮容,特徵宣告包含以下資訊:- 元資料(Metadata):面向特徵使用者的一些描述性資訊;
- 適用工作負載列表(Applies-to list):該特徵可以應用的工作負載列表;
- 屬性(Properties):可以被運維人員配置的屬性。
工作負載型別和配置(Workload types and configurations)
描述特定工作負載的底層執行時,平臺需要能夠提供對應工作負載的執行時,工作負載宣告包含以下資訊:- 元資料(Metadata):面向工作負載使用者的一些描述性資訊;
- 工作負載設定(Workload Setting):可以被運維人員配置的設定。
應用配置(Application configuration)
運維人員使用應用配置將元件、特徵和應用邊界的組合在一起例項化部署,應用配置宣告包含以下資訊:- 元資料(Metadata):面向應用配置使用者的一些描述性資訊;
- 引數覆蓋(Parameter overrides):可以理解為變數定義,可以被元件、特徵、應用邊界的引數引用;
- 元件設定(Component):構成應用的全部元件都在這裡設定;
- 繫結元件的運維特徵配置(Trait Configuration):繫結的特徵列表及其引數。
一個雲原生應用由一組相互關聯但又離散獨立的元件構成,這些元件例項化在合適的執行時上,由配置來控制行為並共同協作提供統一的功能。更加具體的說:
一個 Application 由一組 Components 構成,每個 Component 的執行時由 Workload 描述,每個 Component 可以施加 Traits 來獲取額外的運維能力,同時我們可以使用 Application scopes 將 Components 劃分到 1 或者多個應用邊界中,便於統一做配置、限制、管理。整體的執行模式如下所示:
元件、運維特徵、應用邊界通過應用配置(Application Configuration)例項化,然後再通過 OAM 的實現層翻譯為真實的資源。
怎麼用?
使用 OAM 來管理雲原生應用,其核心主要是圍繞著“四個概念,一個動作”。四個概念
- 應用元件(包含對工作負載的依賴宣告);【開發人員關心】
- 工作負載;【平臺關心】
- 運維特徵;【平臺關心】
- 應用邊界;【平臺關心】
一個動作
- 下發應用配置;【運維人員關心】
- 開發者提供元件,使用平臺的工作負載;
- 運維人員關注一個動作例項化四個概念;
- 平臺方需要提供工作負載,運維特徵,應用邊界,並且託管使用者的應用元件;
例子
如何使用上面“四個概念,一個動作”來部署一個 OAM 應用呢? 我們假想一個場景,使用者的應用有兩個元件:frontend 和 backend,其中 frontend 元件需要域名訪問、自動擴縮容能力,並且 frontend 要訪問 backend,兩者應該在同一個 vpc 內,基於這個場景我們需要有:- 開發者建立 2 個元件
apiVersion: core.oam.dev/v1alpha1
kind: ComponentSchematic
metadata:
name: frontend
annotations:
version: v1.0.0
description: "A simple webserver"
spec:
workloadType: core.oam.dev/v1.Server
parameters:
- name: message
description: The message to display in the web app.
type: string
value: "Hello from my app,too"
containers:
- name: web
env:
- name: MESSAGE
fromParam: message
image:
name: example/charybdis-single:latest複製程式碼
backend 的 workload 是 Cassandra(OAM 平臺提供該工作負載):
apiVersion: core.oam.dev/v1alpha1
kind: ComponentSchematic
metadata:
name: backend
annotations:
version: v1.0.0
description: "Cassandra database"
spec:
workloadType: data.oam.dev/v1.Cassandra
parameters:
- name: maxStalenessPrefix
description: Max stale requests.
type: int
value: 100000
- name: defaultConsistencyLevel
description: The default consistency level
type: string
value: "Eventual"
workloadSettings:
- name: maxStalenessPrefix
fromParam: maxStalenessPrefix
- name: defaultConsistencyLevel
fromParam: defaultConsistencyLevel複製程式碼
- OAM 平臺提供 Ingress Trait
apiVersion: core.oam.dev/v1alpha1
kind: Trait
metadata:
name: Ingress
spec:
type: core.oam.dev/v1beta1.Ingress
appliesTo:
- core.oam.dev/v1alpha1.Server
parameters:
properties: |
{
"$schema": "http://json-schema.org/draft-07/schema#","type": "object","properties": {
"host": {
"type": "string","description": "ingress hosts",},"path": {
"type": "string","description": "ingress path",}
}
}複製程式碼
- OAM 平臺提供網路應用邊界
apiVersion: core.oam.dev/v1alpha1
kind: ApplicationScope
metadata:
name: network
annotations:
version: v1.0.0
description: "network boundary that a group components reside in"
spec:
type: core.oam.dev/v1.NetworkScope
allowComponentOverlap: false
parameters:
- name: network-id
description: The id of the network,e.g. vpc-id,VNet name.
type: string
required: Y
- name: subnet-ids
description: >
A comma separated list of IDs of the subnets within the network. For example,"vsw-123" or ""vsw-123,vsw-456".
There could be more than one subnet because there is a limit in the number of IPs in a subnet.
If IPs are taken up,operators need to add another subnet into this network.
type: string
required: Y
- name: internet-gateway-type
description: The type of the gateway,options are 'public','nat'. Empty string means no gateway.
type: string
required: N複製程式碼
apiVersion: core.oam.dev/v1alpha1
kind: ApplicationConfiguration
metadata:
name: my-vpc-network
spec:
variables:
- name: networkName
value: "my-vpc"
scopes:
- name: network
type: core.oam.dev/v1alpha1.Network
properties:
- name: network-id
value: "[fromVariable(networkName)]"
- name: subnet-ids
value: "my-subnet1,my-subnet2"複製程式碼
- 應用運維部署整個應用
apiVersion: core.oam.dev/v1alpha1
kind: ApplicationConfiguration
metadata:
name: custom-single-app
annotations:
version: v1.0.0
description: "Customized version of single-app"
spec:
variables:
- name: message
value: "Well hello there"
- name: domainName
value: "www.example.com"
components:
- componentName: frontend
instanceName: web-front-end
parameterValues:
- name: message
value: "[fromVariable(message)]"
traits:
- name: Ingress
properties:
- name: host
value: "[fromVaraible(domainName)]"
- name: path
value: "/"
applicationScopes:
- my-vpc-network
- componentName: backend
instanceName: database
applicationScopes:
- my-vpc-network複製程式碼
通過以上完整的使用流程我們可以看到:應用配置是真正部署應用的起點,在使用該配置的時候,對應的元件、應用邊界、特徵都要提前部署好,運維人員只需做一個組合即可。
服務元件(Component Schematic)
服務元件的意義是讓開發者宣告離散執行單元的執行時特性,可以用 JSON/YAML 格式來表示,其宣告遵循 Kubernetes API 規範,區別在於:- 定義欄位是 Kubernetes 的子集,因為 OAM 是更高的抽象;
- OAM Spec 的底層執行時可以不是 Kubernetes
定義
頂層屬性
屬性型別必填預設值描述apiVersionstringY特定oam spec版本,比如core.oam.dev/v1kindstringY型別,對於元件來說就是 ComponentSchematicmetadataMetadataY元件元資料specSpecY元件特定的定義屬性Metadata
屬性型別必填預設值描述namestringYlabelsmap[string]stringNk/v對作為元件的lebelsannotationsmap[string]stringNk/v對作為元件的描述資訊Spec
屬性型別必填預設值描述parameters[]ParameterN元件的可配置項workloadTypestringY簡明語義化的元件執行時描述,以K8s為例就是指定底層使用StatefulSet還是Deployment這樣osTypestringNlinux元件容器執行時依賴的作業系統型別,可選值: - linux - windows archstringNamd64元件容器執行時依賴的CPU架構,可選值: - i386 - amd64 - arm - arm64 containers[]ContainerN實現元件的OCI容器們workloadSettings[]WorkloadSettingsN需要傳給工作負載執行時的非容器配置宣告 上面的 workloadType 後面會有詳細說明,這裡簡要來說就是開發者可以指定該 field 告訴執行時該元件如何被執行。工作負載命名的規範是 GROUP/VERSION.KIND,和 K8s 資源型別座標一致,比如:- core.oam.dev/v1alpha1.Singleton
- alibabacloud.com/v1.Function
- streams.oam.io/v1beta2.Kafka
- 核心工作負載型別
- Server:定義了容器執行時可以執行 0 或多個容器例項,該工作負載提供了冗餘的可擴縮容的多副本常駐服務,在 K8s 平臺可以使用 Deployment 或者 Statefulset 加上 Service 來實現;
- Singleton Server:定義了容器執行時只能執行一個容器例項,該工作負載提供了無法冗餘的單副本常駐服務,在 K8s 平臺可以使用副本為 1 的 Statefulset 加上 Service 來實現;
- Worker:定義了容器執行時可以執行 0 或多個容器例項,該工作負載提供了冗餘的可擴縮容的多副本常駐例項但是不提供服務,在 K8s 平臺可以使用 Deployment 或者 Statefulset 來實現;
- Singleton Worker:定義了容器執行時只能執行一個容器例項,該工作負載提供了無法冗餘的單副本常駐例項但是不提供服務,在 K8s 平臺可以使用副本為 1 的 Statefulset 來實現;
- Task:定義了非常駐可冗餘的容器執行時,執行完就退出,可以賦予擴縮容特性,在 K8s 平臺可以使用 Job 來實現;
- Singleton Task:定義了非常駐非冗餘的容器執行時,執行完就退出,在 K8s 平臺可以使用 completions=1 的 Job 來實現。
- 擴充套件工作負載型別
- 丟失了期望的 k/v 對;
- 不認識的 k/v 對;
例子
使用核心工作負載 Server 的元件宣告
apiVersion: core.oam.dev/v1alpha1
kind: ComponentSchematic
metadata:
name: frontend
annotations:
version: v1.0.0
description: >
Sample component schematic that describes the administrative interface for our Twitter bot.
spec:
workloadType: core.oam.dev/v1alpha1.Server
osType: linux
parameters:
- name: username
description: Basic auth username for accessing the administrative interface
type: string
required: true
- name: password
description: Basic auth password for accessing the administrative interface
type: string
required: true
- name: backend-address
description: Host name or IP of the backend
type: string
required: true
containers:
- name: my-twitter-bot-frontend
image:
name: example/my-twitter-bot-frontend:1.0.0
digest: sha256:6c3c624b58dbbcd3c0dd82b4c53f04194d1247c6eebdaab7c610cf7d66709b3b
resources:
cpu:
required: 1.0
memory:
required: 100MB
ports:
- name: http
value: 8080
env:
- name: USERNAME
fromParam: 'username'
- name: PASSWORD
fromParam: 'password'
- name: BACKEND_ADDRESS
fromParam: 'backend-address'
livenessProbe:
httpGet:
port: 8080
path: /healthz
readinessProbe:
httpGet:
port: 8080
path: /healthz複製程式碼
使用擴充套件工作負載的元件宣告
apiVersion: core.oam.dev/v1alpha1
kind: ComponentSchematic
metadata:
name: alibabacloudFunctions
annotations:
version: v1.0.0
description: "Extended workflow example"
spec:
workloadType: alibabacloud.com/v1.Function
parameters:
- name: github-token
description: GitHub API session key
type: string
required: true
workloadSettings:
- name: source
value: git://git.example.com/function/myfunction.git
- name: github_token
fromParam: github-token複製程式碼
總結
元件宣告是由開發者或者 OAM 平臺給出,透出應用執行的可配置項、依賴的平臺和工作負載,可以看成是一個宣告瞭執行環境的函式定義,運維人員填寫函式引數之後,元件就會按照宣告的功能執行起來。應用邊界(Application scopes)
應用邊界通過提供不同形式的應用邊界以及共有的分組行為來將元件組成邏輯的應用,應用邊界具備以下通用的特徵:- 應用邊界應該描述該組元件例項的共有行為和元資料;
- 一個元件可以同時部署到多個不同型別的應用邊界中;
- 應用邊界型別可以決定元件是否可以部署到多個相同的應用邊界型別例項;
- 應用邊界可以用於不同元件分組以及不同 infra 能力之間的連線機制,比如 networking 或者外部能力(如驗證服務);
上圖有兩種應用邊界型別:Network 與 Health,有四個元件分佈在不同的應用邊界例項中:
- A、B、C 三個元件部署到了相同的 Health scope,該 scope 會收集所有屬於這個邊界的元件狀態和資訊,可以給 Traits 或者其他元件使用;
- 元件 A 和 B、C、D 的網路邊界是隔離的,這允許 infra 運維提供不同的 SDN 設定,控制不同分組的流量流入/流出規則;
型別
主要是有兩種應用邊界型別:- 核心應用邊界型別
- 擴充套件應用邊界型別
核心應用邊界型別
定義基本執行時行為的分組結構,它們擁有如下特徵:- 必須是 core.oam.dev 名稱空間;
- 必須被全部實現;
- 核心工作負載型別例項必須部署到所有核心應用邊界型別例項中;
- 執行時必須為每種應用邊界型別提供預設的應用邊界例項;
- 執行時如果元件例項沒有指定特定的應用邊界,必須將該元件例項部署到預設應用邊界例項上;
擴充套件應用邊界型別
對於執行時來說是 optional 的,可以自定義。定義
apiVersion,kind,metadata 和前面元件一致,不贅述,主要描述 Spec: 屬性型別必填預設值描述typestringY應用邊界型別allowComponentOverlapboolY決定是否允許一個元件同時出現在多個該型別應用邊界例項中parameters[]ParameterN邊界的可配置引數例子
Network scope(core)
用於將元件劃分到一個網路或者 SDN 中,網路本身必須被 infra 定義和運維,也可以被流量管理 Traits 查詢,用於發現 service mesh 的可發現邊界或者 API 閘道器的 API 邊界:apiVersion: core.oam.dev/v1alpha1
kind: ApplicationScope
metadata:
name: network
annotations:
version: v1.0.0
description: "network boundary that a group components reside in"
spec:
type: core.oam.dev/v1.NetworkScope
allowComponentOverlap: false
parameters:
- name: network-id
description: The id of the network,VNet name.
type: string
required: Y
- name: subnet-id
description: The id of the subnet within the network.
type: string
required: Y
- name: internet-gateway-type
description: The type of the gateway,options are 'public','nat'. Empty string means no gateway.
type: string
required: N複製程式碼
Health scope(core)
用於聚合元件的健康狀態,可以設計的引數有健康閾值(超過該閾值的元件不健康則認為整個邊界不健康),健康邊界例項本身不會用健康狀態做任何操作,它只是分組健康聚合器,其資訊可以被查詢並用於其他地方,比如:- 應用的變更 Traits 可以監控健康狀態來決定何時回滾;
- 監控 Traits 可以監控健康狀態來觸發報警。
apiVersion: core.oam.dev/v1alpha1
kind: ApplicationScope
metadata:
name: health
annotations:
version: v1.0.0
description: "aggregated health state for a group of components."
spec:
type: core.oam.dev/v1alpha1.HealthScope
allowComponentOverlap: true
parameters:
- name: probe-method
description: The method to probe the components,e.g. 'httpGet'.
type: string
required: true
- name: probe-endpoint
description: The endpoint to probe from the components,e.g. '/v1/health'.
type: string
required: true
- name: probe-timeout
description: The amount of time in seconds to wait when receiving a response before marked failure.
type: integer
required: false
- name: probe-interval
description: The amount of time in seconds between probing tries.
type: integer
required: false
- name: failure-rate-threshold
description: If the rate of failure of total probe results is above this threshold,declared 'failed'.
type: double
required: false
- name: healthy-rate-threshold
description: If the rate of healthy of total probe results is above this threshold,declared 'healthy'.
type: double
required: false
- name: health-threshold-percentage
description: The % of healthy components required to upgrade scope
type: double
required: false
- name: required-healthy-components
description: Comma-separated list of names of the components required to be healthy for the scope to be health.
type: []string
required: false複製程式碼
resource quota scope(extended)
限制分組內所有元件的資源使用總量上限。apiVersion: core.oam.dev/v1alpha1
kind: ApplicationScope
metadata:
name: myResourceQuotas
annotations:
version: v1.0.0
description: "The production configuration for Corp CMS"
spec:
type: resources.oam.dev/v1.ResourceQuotaScope
allowComponentOverlap: false
parameters:
- name: CPU
description: maximum CPU to be consumed by this scope
type: double
required: Y
- name: Memory
description: maximum memory to be consumed by this scope
type: double
required: Y複製程式碼
總結
應用邊界宣告由 OAM 平臺提供,透出應用邊界例項執行的可配置項,可以看成是一個函式定義,運維人員或者平臺填寫函式引數之後,應用邊界就會按照宣告的功能執行起來,對該邊界內的元件們起作用。應用特徵(Traits)
OAM Spec 的實現平臺應該提供 Traits 給元件工作負載增強運維操作,一個 Trait 是一種自由的執行時,增強工作負載提供額外的功能,比如流量路由規則、自動擴縮容規則、升級策略等,這讓應用運維具備根據需求配置元件,不需要開發者參與的能力。一個獨立的 Trait 可以繫結 1 或多個工作負載型別,它可以宣告哪些工作負載型別才能使用該Trait。規則
- 目前並沒有機制來顯示約定元件的多個 Traits 組合,也就是一個元件應用了 Trait A 無法要求 Trait B 必須應用於該元件,如果在執行時發生存在 Trait A 但是 Trait B 不存在,應該標記 Trait A 失敗;
- Traits 應該按照定義的順序施加到元件上;
- 應用部署只有當所有元件和其 Traits 都正常執行起來才能標記為部署成功;
- OAM 平臺應該支援元件施加多個 Traits,這些 Traits 可能是相同的型別;
- OAM 對 Trait 的實現沒有任何限制,Trait 一般作用於應用的安裝和升級時;
分類
目前 Traits 主要分為三類:- Core Traits: core Traits 屬於 core.oam.dev 分組,是一些必要的運維特徵,所有 OAM 平臺必須實現;
- Standard Traits: standard Traits 屬於 standard.oam.dev 分組裡面,是一些常用的運維特徵,推薦 OAM 平臺實現;
- Extensions Traits: extension Traits 是自定義 Traits,其分組也是自定義,是平臺特定的運維特徵(通常是特定 OAM 平臺差異性)的體現。
定義
apiVersion,kind,metadata 和前面元件一致,不贅述,主要描述 Spec: 屬性型別必填預設值描述appliesTo[]stringN["*"]該Trait可以應用的工作負載型別properties[]PropertiesNTrait的可配置引數,使用JSON Schema來表達。例子
Manual Scaler(core)
apiVersion: core.oam.dev/v1alpha1
kind: Trait
metadata:
name: ManualScaler
annotations:
version: v1.0.0
description: "Allow operators to manually scale a workloads that allow multiple replicas."
spec:
appliesTo:
- core.oam.dev/v1alpha1.Server
- core.oam.dev/v1alpha1.Worker
- core.oam.dev/v1alpha1.Task
properties: |
{
"$schema": "http://json-schema.org/draft-07/schema#","required": ["replicaCount],"properties": {
"replicaCount": {
"type": "integer","description": "the target number of replicas to scale a component to.","minimum": 0
}
}
}複製程式碼
上面是一個手動擴縮容服務的 Trait,只有一個引數就是 replicaCount。
總結
應用特徵宣告由 OAM 平臺提供,透出應用特徵的可配置項,標明瞭可作用於的工作負載,可以看成函式定義,運維人員或者平臺填寫實參之後,應用特徵就會按照宣告的功能執行起來,對繫結的元件起作用。應用配置(Application Configuration)
應用配置主要是描述應用如何被部署的,一個元件可以部署到任意的執行時,我們稱一個元件的一次部署為例項,每次元件部署的時候必須有應用配置。 應用配置由應用運維管理,提供當前元件例項的資訊:- 特定元件的基本資訊:名字、版本、描述;
- 元件及其相關元件定義 parameters 的賦值;
- 元件要施加的 Trait 以及 Trait 的配置。
概念
例項與升級(Instances and upgrades)
一個例項是元件的可追溯部署,當元件部署時建立,後續該元件的升級都是修改該例項,回滾/重新部署都屬於升級,例項都會有名字方便引用。當一個例項首次建立時,處於初始發行 (release) 狀態,每次升級操作之後,一個新的發行就會建立。發行(Releases)
任何對元件本身或者其配置的變更都會建立一個新的發行,一個發行就是應用配置以及它對元件、應用特徵、應用邊界的定義,當一個發行被部署,對應的元件、應用特徵和應用邊界也會被部署。 基於該定義,平臺需要保證以下變更語義:- 如果新的發行包含了舊發行不存在的元件,平臺需要建立該元件;
- 如果新的發行不包含舊發行存在的元件,平臺需要刪除該元件;
- 應用特徵和應用邊界與元件的變更語義一致。
執行時與應用配置(Runtime and Application Configuration)
一個元件可以部署到多個不同的執行時,在每個執行時中應用配置的例項與應用配置之間是 1:1 的關係,應用配置由應用運維管理,包含 3 個主要部分:- 引數:運維人員在部署時可以定義的引數;
- 應用邊界列表:一組應用邊界列表,每個應用邊界定義對應的引數;
- 元件例項定義:定義一個元件例項如何部署,這個定義本身有 3 個部分:
- 元件引數的定義;
- Traits 列表:每個 Trait 定義對應的引數;
- 應用邊界列表:該元件應該部署到的應用邊界列表。
定義
apiVersion,kind,metadata 和前面元件一致,不贅述,主要描述 Spec: 屬性型別必填預設值描述variables[]VariableN可以在引數值和屬性中引用的變數scopes[]ScopeN應用邊界定義components[]ComponentN元件例項定義 variables 就是一個 k/v 對,一個集中的地方定義運維的變數,在運維配置的其他地方都可以用 fromVariable(VARNAME) 引用: 屬性型別必填預設值描述namestringY變數名字valuestringY標量值 scopes 定義該運維配置將要建立的應用邊界,其定義為: 屬性型別必填預設值描述namestringY應用邊界名字typestringY應用邊界的GROUP/VERSION.KINDpropertiesPropertiesN覆蓋邊界的引數 components 是元件例項定義,而不是元件定義: 屬性型別必填預設值描述componentNamestringY元件名instanceNamestringY元件例項名parameterValues[]ParameterValueN覆蓋元件的引數Traits[]TraitN指定元件例項繫結的TraitsapplicationScopes[]stringN指定元件執行的應用邊界 Trait 在這裡的定義是: 屬性型別必填預設值描述namestringYTrait例項名propertiesPropertiesN覆蓋Trait的引數例子
apiVersion: core.oam.dev/v1alpha1
kind: ApplicationConfiguration
metadata:
name: my-app-deployment
annotations:
version: v1.0.0
description: "Description of this deployment"
spec:
variables:
- name: VAR_NAME
value: SUPPLIED_VALUE
scopes:
- name: core.oam.dev/v1alpha1.Network
parameterValues:
- name: PARAM_NAME
value: SUPPLIED_VALUE
components:
- componentName: my-web-app-component
instanceName: my-app-frontent
parameterValues:
- name: PARAMETER_NAME
value: SUPPLIED_VALUE
- name: ANOTHER_PARAMETER
value: "[fromVariable(VAR_NAME)]"
traits:
- name: Ingress
properties:
CUSTOM_OBJECT:
DATA: "[fromVariable(VAR_NAME)]"複製程式碼
總結
應用配置定義由運維人員或者 OAM 平臺提供,描述應用的部署,可以看成是一個函式呼叫,運維人員或者 OAM 平臺填寫實參之後,呼叫之前定義的元件、應用特徵、應用邊界等函式,這些例項一起作用對外提供應用服務。工作負載型別(Workload Types)
Workload 型別和 Trait 一樣由平臺提供,所以使用者可以檢視平臺提供哪些工作負載,對於平臺使用者來說工作負載型別無法擴充套件,只能由平臺開發者擴充套件提供,因此平臺一定不允許使用者建立自定義的工作負載型別。定義
apiVersion,kind,metadata 和前面元件類似,不贅述,這裡主要描述 Spec,定義元件如何使用工作負載型別,除此之外暴露了底層工作負載執行時的可配置引數: 屬性型別必填預設值描述groupstringY該工作負載型別所屬的groupnamesNamesY該工作負載型別的關聯名字資訊settings[]SettingN該工作負載的設定選項 Names 就是描述了對應型別的不同形式名字引用: 屬性型別必填預設值描述kindstringY工作負載型別的正確引用名字,比如SingletonsingularstringN單數形式的可讀名字,比如singletonpluralstringN複數形式的可讀名字,比如singletons Setting 描述工作負載可配置部分,類似前面元件的 Parameters,都是 schema: 屬性型別必填預設值描述namestringY配置名,每個workload型別必須唯一descriptionstringN配置說明typestringY配置型別requiredboolNfalse是否必須提供defaultindicated by typeN預設值價值
通過上面的介紹,我們瞭解了 OAM Spec 裡面的基本概念和定義,以及如何使用它們來描述應用交付和運維流程。然而,OAM 能給我們帶來什麼樣的價值呢?我們評判一個好的架構體系,不僅是因為它在技術上更先進,更主要的是它能夠解決一些實際問題,為使用者帶來價值。所以,接下來我們將總結一下這方面的內容。 OAM 的價值要從下往上三個層面來說起。1. 從基礎設施層面
基礎設施,指的是像 K8s 這類的提供基礎服務能力與抽象的一層服務體系。拿 K8s 來說,它提供了許多種類的基礎服務和強大的擴充套件能力來靈活擴充套件其他基礎服務。 但是,使用基礎設施的運維人員很快就發現 K8s 存在一個問題:缺乏統一的機制來註冊和管理自定義擴充套件能力。這些擴充套件能力的表達方式不夠統一,有些是 CRD、有些是 annotation、有些是 Config... 這種亂象使得基礎設施使用者不知道平臺上都提供了哪些能力,不知道怎麼使用這些能力,更不知道這些能力互相之間的相容組合關係。 OAM 提供了抽象(如 Workload/Trait 等)來統一定義和管理這些能力。有了 OAM,各平臺實現就有了統一的標準規範去透出公共的或差異化的能力:公共的基礎服務像容器部署、監控、日誌、灰度釋出;差異化的、高階複雜的能力像 CronHPA(週期性定時變化的強化版 HPA)。2. 從應用運維者層面
應用運維,指的是像給應用加上網路接入、複雜均衡、彈性伸縮、甚至是建站等運維操作。但是,運維的一個痛點就是原來這些能力並不是跨平臺的:這導致在不同平臺、不同環境下去部署和運維應用的操作,是不互通和不相容的。 上面這個問題,是客戶應用、尤其是傳統 ERP 應用上雲的一大阻礙。我們做 OAM 的一個初衷,就是通過一套標準定義,讓不同的平臺實現也通過統一的方式透出。我們希望:哪怕一個應用不是生在雲上、長在雲上,也能夠趕上這趟通往雲原生未來的列車,擁抱雲帶來的變化和紅利! OAM 提供的抽象和模型,是我們通往統一、標準的應用架構的強有力工具。這些標準能力以後都會通過 OAM 輸出,讓運維人員輕易去實現跨平臺部署。3. 從應用開發者層面
應用開發,指的就是業務邏輯開發,這是業務產生價值的核心位置。 也正因如此,我們希望,應用開發者能夠專注於業務開發,而不需要關心運維細節。但是,K8s 提供的 API,並沒有很好地分離開發和運維的關注點,開發和運維之間需要來回溝通以避免產生誤解和衝突。 OAM 分離了開發和運維的關注點,很好地解決了以上問題,讓整個釋出流程更加連貫、高效。下一步
目前,OAM 已經在阿里雲 EDAS 等多個專案中進行了數月的內部落地嘗試。我們希望通過一套統一、標準的應用定義體系,承載雲應用管理專案產品與外部資源關係的高效管理體驗,並將這種體驗統一帶給了基於 Function、ECS、Kubernetes 等不同執行時的應用管理流程;通過應用特徵系統,將多個阿里雲獨有的能力進行了模組化,大大提高了阿里雲基礎設施能力的交付效率。 經過了前一段努力的鋪墊,我們也慢慢明確了接下來的工作方向:- 將接入更多的雲產品服務,為使用者將跨平臺應用交付的能力最大化;
- 提供 OAM framework 等工具和框架,幫助新的 OAM 平臺開發者去快速、簡單地搭建 OAM 服務,接入 OAM 標準;
- 推動開源生態建設,以標準化的方式幫助“應用”高效和高質量地交付到任何平臺上去。
原文連結 本文為雲棲社群原創內容,未經允許不得轉載。