漸進式交付的重要性
在現代軟體交付實務中,傳統的一次性全量發布策略已經無法滿足高可用性服務的需求。當新版本應用程式直接替換所有執行中的實例時,任何潛在的缺陷都會立即影響全部使用者。這種高風險的發布方式在早期軟體開發時代或許可以接受,但在當今講求持續交付與零停機時間的雲端原生環境中,已經成為不可承受的風險。
漸進式交付提供了更安全的替代方案,透過分階段逐步推出新版本,在小範圍內驗證其穩定性與效能後再擴大部署範圍。這種策略讓團隊能夠在早期發現問題並快速回滾,將潛在影響限制在最小範圍內。金絲雀發布作為漸進式交付的代表性技術,其名稱源自礦工使用金絲雀偵測有毒氣體的歷史實務。礦工會攜帶金絲雀進入礦坑,如果鳥兒出現異常反應甚至死亡,就警示著危險氣體的存在,礦工得以及時撤離避免傷亡。
在軟體發布的脈絡中,少部分率先體驗新版本的使用者就如同那隻金絲雀,他們的使用體驗與系統指標成為新版本品質的早期指標。如果監控資料顯示錯誤率上升、回應時間延長或資源消耗異常,團隊可以立即暫停發布並回滾到穩定版本。相反地,如果所有指標都保持健康,則可以信心十足地將流量逐步遷移到新版本,最終完成全量替換。
Argo Rollouts作為Kubernetes生態系統中的漸進式交付工具,擴展了原生Deployment控制器的能力。標準的Deployment雖然支援滾動更新,但其流量控制粒度粗糙,僅能透過Pod數量間接影響流量分配,無法實現精確的百分比控制。Argo Rollouts引入了Rollout自訂資源,提供宣告式的發布策略定義,支援金絲雀發布、藍綠佈署等多種進階模式,並能與Istio等服務網格技術深度整合,實現網路層級的精確流量管理。
Rollout資源深度解析
Rollout資源是Argo Rollouts的核心抽象,它與Kubernetes原生的Deployment資源在語法上高度相似,但增加了strategy區段用於定義發布策略。這種設計降低了學習曲線,熟悉Deployment的開發人員可以快速上手Rollout的使用。
一個完整的Rollout資源定義包含應用程式的基本資訊、副本配置、Pod範本以及最關鍵的發布策略。金絲雀策略透過steps欄位定義發布的各個階段,每個步驟可以設定流量權重與暫停條件,形成完整的發布流程編排。
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: web-application
namespace: production
labels:
app: web-service
version: v2
spec:
replicas: 10
revisionHistoryLimit: 5
selector:
matchLabels:
app: web-service
template:
metadata:
labels:
app: web-service
version: v2
spec:
containers:
- name: application
image: registry.company.com/web-service:2.0.0
ports:
- name: http
containerPort: 8080
protocol: TCP
env:
- name: ENVIRONMENT
value: production
- name: LOG_LEVEL
value: info
resources:
requests:
memory: 512Mi
cpu: 250m
limits:
memory: 1Gi
cpu: 500m
livenessProbe:
httpGet:
path: /healthz
port: http
initialDelaySeconds: 30
periodSeconds: 10
readinessProbe:
httpGet:
path: /ready
port: http
initialDelaySeconds: 5
periodSeconds: 5
strategy:
canary:
maxSurge: 2
maxUnavailable: 0
steps:
- setWeight: 10
- pause: {duration: 2m}
- setWeight: 20
- pause: {duration: 2m}
- setWeight: 40
- pause: {}
- setWeight: 60
- pause: {duration: 5m}
- setWeight: 80
- pause: {duration: 5m}
這個Rollout定義展示了金絲雀發布的完整配置。replicas欄位設定應用程式的總副本數為10個,在發布過程中Argo Rollouts會動態調整新舊版本的副本分配以達到目標流量權重。revisionHistoryLimit控制保留的歷史版本數量,這些歷史版本在需要快速回滾時發揮關鍵作用。
strategy區段是Rollout資源的核心特色。canary策略首先透過maxSurge與maxUnavailable控制發布過程中的資源波動。maxSurge允許在發布期間臨時超出期望副本數,這裡設定為2表示最多可以同時存在12個Pod。maxUnavailable設定為0確保整個發布過程中始終維持足夠的可用副本,避免服務容量下降。
steps陣列定義了金絲雀發布的具體階段。每個階段由setWeight設定目標流量權重與pause控制推進節奏組成。第一階段將10%流量導向新版本並暫停2分鐘,這段時間內團隊可以觀察監控指標,確認新版本在小規模流量下的表現。接著逐步提升到20%並再次暫停,然後跳躍到40%。在40%這個關鍵點,pause沒有設定duration,這表示發布會無限期暫停,等待手動介入推進。這種手動檢查點讓團隊在承擔更大風險前有機會進行深入的驗證與評估。
後續階段繼續提升流量至60%與80%,每個階段都給予較長的5分鐘觀察時間。這種漸進式的流量遷移策略確保了問題能夠在影響少數使用者時被偵測到,大幅降低了發布風險。
@startuml
!define PLANTUML_FORMAT svg
!theme _none_
skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100
package "穩定版本 v1" as stable {
component "Pod-1" as pod1_stable
component "Pod-2" as pod2_stable
component "Pod-3" as pod3_stable
component "Pod-4" as pod4_stable
component "Pod-5" as pod5_stable
}
package "金絲雀版本 v2" as canary {
component "Pod-1" as pod1_canary
component "Pod-2" as pod2_canary
}
actor "使用者流量" as users
users -down-> pod1_canary : 20%流量
users -down-> pod1_stable : 80%流量
users -down-> pod2_stable : 80%流量
users -down-> pod3_stable : 80%流量
users -down-> pod4_stable : 80%流量
users -down-> pod5_stable : 80%流量
note right of canary
階段2: 20%金絲雀流量
觀察期: 2分鐘
監控指標:
- 錯誤率
- 回應時間
- CPU/記憶體使用
end note
note left of stable
維持穩定版本運作
承載大部分流量
隨時準備接管全部流量
end note
@enduml金絲雀發布執行流程
理解Rollout資源的宣告式定義後,實際執行金絲雀發布需要經歷初始部署、版本更新、階段推進等多個環節。Argo Rollouts控制器會持續監控Rollout資源的期望狀態與實際狀態,協調整個發布流程的執行。
初次部署Rollout資源時,由於不存在先前版本,Argo Rollouts會直接建立所有期望的副本數,金絲雀策略在這個階段不會生效。這確保了新應用程式能夠快速上線,不必經歷漸進式發布的冗長流程。
kubectl apply -f web-application-rollout.yaml
# 驗證Rollout資源建立
kubectl get rollout web-application -n production
# 觀察Pod建立過程
kubectl get pods -n production -l app=web-service -w
部署完成後可以使用Argo Rollouts的kubectl外掛程式獲取詳細的狀態資訊。這個外掛程式提供了視覺化的樹狀結構,清楚展示Rollout與其管理的ReplicaSet及Pod之間的層級關係。
kubectl argo rollouts get rollout web-application -n production --watch
輸出會顯示類似以下的資訊結構,包含整體健康狀態、當前階段、流量權重分配以及各個資源的詳細狀態。
Name: web-application
Namespace: production
Status: ✔ Healthy
Strategy: Canary
Step: 8/8
SetWeight: 100
ActualWeight: 100
Images: registry.company.com/web-service:2.0.0 (stable)
Replicas:
Desired: 10
Current: 10
Updated: 10
Ready: 10
Available: 10
NAME KIND STATUS AGE INFO
⟳ web-application Rollout ✔ Healthy 15m
└──# revision:1
└──⧉ web-application-7d9c8bf5f ReplicaSet ✔ Healthy 15m stable
├──□ web-application-7d9c8bf5f-2xk8n Pod ✔ Running 15m ready:1/1
├──□ web-application-7d9c8bf5f-4m7p2 Pod ✔ Running 15m ready:1/1
├──□ web-application-7d9c8bf5f-6q9s5 Pod ✔ Running 15m ready:1/1
├──□ web-application-7d9c8bf5f-8t3n7 Pod ✔ Running 15m ready:1/1
├──□ web-application-7d9c8bf5f-9w4k1 Pod ✔ Running 15m ready:1/1
├──□ web-application-7d9c8bf5f-c5r6m Pod ✔ Running 15m ready:1/1
├──□ web-application-7d9c8bf5f-h2v8p Pod ✔ Running 15m ready:1/1
├──□ web-application-7d9c8bf5f-j7x3q Pod ✔ Running 15m ready:1/1
├──□ web-application-7d9c8bf5f-m9z4t Pod ✔ Running 15m ready:1/1
└──□ web-application-7d9c8bf5f-p1b6w Pod ✔ Running 15m ready:1/1
當需要發布新版本時,只需更新Rollout資源中的映像標籤或其他Pod規格欄位。Argo Rollouts偵測到變更後會自動啟動金絲雀發布流程,建立新的ReplicaSet並按照策略定義逐步遷移流量。
# 更新映像版本觸發金絲雀發布
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: web-application
namespace: production
spec:
template:
spec:
containers:
- name: application
image: registry.company.com/web-service:2.1.0 # 版本更新
套用更新後,Argo Rollouts會開始執行金絲雀策略。在第一階段,控制器會建立1個新版本的Pod(10個總副本的10%),並將其標記為canary。這時檢查Pod狀態會看到新舊版本並存的情況。
kubectl apply -f web-application-rollout-v2.yaml
# 觀察Pod變化
kubectl get pods -n production -l app=web-service
NAME READY STATUS RESTARTS AGE
web-application-7d9c8bf5f-2xk8n 1/1 Running 0 25m
web-application-7d9c8bf5f-4m7p2 1/1 Running 0 25m
web-application-7d9c8bf5f-6q9s5 1/1 Running 0 25m
web-application-7d9c8bf5f-8t3n7 1/1 Running 0 25m
web-application-7d9c8bf5f-9w4k1 1/1 Running 0 25m
web-application-7d9c8bf5f-c5r6m 1/1 Running 0 25m
web-application-7d9c8bf5f-h2v8p 1/1 Running 0 25m
web-application-7d9c8bf5f-j7x3q 1/1 Running 0 25m
web-application-7d9c8bf5f-m9z4t 1/1 Running 0 25m
web-application-9f6b2cd8a-x5k9r 1/1 Running 0 30s
使用kubectl外掛程式可以清楚看到發布處於暫停狀態,等待手動推進或自動計時器到期。
kubectl argo rollouts get rollout web-application -n production
Name: web-application
Namespace: production
Status: ॥ Paused
Message: CanaryPauseStep
Strategy: Canary
Step: 1/8
SetWeight: 10
ActualWeight: 10
Images: registry.company.com/web-service:2.0.0 (stable)
registry.company.com/web-service:2.1.0 (canary)
Replicas:
Desired: 10
Current: 10
Updated: 1
Ready: 10
Available: 10
NAME KIND STATUS AGE INFO
⟳ web-application Rollout ॥ Paused 28m
├──# revision:2
│ └──⧉ web-application-9f6b2cd8a ReplicaSet ✔ Healthy 1m15s canary
│ └──□ web-application-9f6b2cd8a-x5k9r Pod ✔ Running 1m15s ready:1/1
└──# revision:1
└──⧉ web-application-7d9c8bf5f ReplicaSet ✔ Healthy 28m stable
├──□ web-application-7d9c8bf5f-2xk8n Pod ✔ Running 28m ready:1/1
├──□ web-application-7d9c8bf5f-4m7p2 Pod ✔ Running 28m ready:1/1
├──□ web-application-7d9c8bf5f-6q9s5 Pod ✔ Running 28m ready:1/1
├──□ web-application-7d9c8bf5f-8t3n7 Pod ✔ Running 28m ready:1/1
├──□ web-application-7d9c8bf5f-9w4k1 Pod ✔ Running 28m ready:1/1
├──□ web-application-7d9c8bf5f-c5r6m Pod ✔ Running 28m ready:1/1
├──□ web-application-7d9c8bf5f-h2v8p Pod ✔ Running 28m ready:1/1
├──□ web-application-7d9c8bf5f-j7x3q Pod ✔ Running 28m ready:1/1
└──□ web-application-7d9c8bf5f-m9z4t Pod ✔ Running 28m ready:1/1
在這個暫停階段,團隊應該密切監控新版本的指標,包含應用程式層級的錯誤率與回應時間,以及基礎設施層級的CPU與記憶體使用。如果所有指標都符合預期,可以手動推進到下一階段。
kubectl argo rollouts promote web-application -n production
promote指令會觸發Argo Rollouts繼續執行後續階段。控制器會調整副本數達到20%的流量權重,建立額外的金絲雀Pod並縮減部分穩定版本Pod。這個過程會自動進行,無需人工干預Pod的建立與刪除。
如果在任何階段發現問題,可以立即中止發布並回滾到穩定版本。abort指令會停止金絲雀發布,刪除所有金絲雀Pod並確保流量完全回到穩定版本。
kubectl argo rollouts abort web-application -n production
中止後如果需要重新嘗試發布,可以使用retry指令重新啟動金絲雀流程,或者修正問題後更新Rollout資源觸發新的發布。
@startuml
!define PLANTUML_FORMAT svg
!theme _none_
skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100
participant "維運人員" as ops
participant "kubectl" as kubectl
participant "Argo Rollouts\n控制器" as controller
participant "Kubernetes\nAPI" as k8s
participant "Prometheus" as prom
ops -> kubectl : 更新映像版本
activate kubectl
kubectl -> k8s : 套用Rollout變更
deactivate kubectl
activate controller
controller -> k8s : 偵測Rollout更新
k8s --> controller : 回傳新期望狀態
controller -> controller : 解析金絲雀策略
controller -> k8s : 建立金絲雀ReplicaSet
activate k8s
k8s -> k8s : 啟動1個金絲雀Pod(10%)
k8s --> controller : Pod就緒通知
deactivate k8s
controller -> controller : 進入暫停狀態\n(duration: 2m)
controller --> ops : 顯示暫停狀態
deactivate controller
activate ops
ops -> prom : 查詢金絲雀指標
activate prom
prom --> ops : 錯誤率: 0.1%\n回應時間: 85ms
deactivate prom
ops -> ops : 評估指標健康度
ops -> kubectl : promote推進發布
deactivate ops
activate kubectl
kubectl -> controller : 觸發下一階段
deactivate kubectl
activate controller
controller -> k8s : 調整副本配置
activate k8s
k8s -> k8s : 擴展到2個金絲雀Pod(20%)
k8s -> k8s : 縮減1個穩定Pod
k8s --> controller : 副本調整完成
deactivate k8s
controller -> controller : 暫停2分鐘
controller --> ops : 階段2完成,等待中
deactivate controller
note right of controller
自動協調流程
動態調整副本數
維持流量權重
支援手動介入
end note
@endumlIstio服務網格整合
雖然基於Pod副本數的流量控制簡單直觀,但在實務中存在明顯的局限性。當需要將5%流量導向金絲雀版本時,必須將總副本數設定為20的倍數才能實現精確控制,這在小規模部署中不切實際。此外,Pod層級的控制無法處理更複雜的路由需求,例如根據HTTP標頭、Cookie或使用者身份導向特定版本。
Istio等服務網格技術在網路層提供了精確的流量管理能力。透過在每個Pod中注入Envoy代理,Istio能夠攔截所有進出流量並根據配置的路由規則進行智慧分發。Argo Rollouts與Istio的整合充分利用了這種能力,將金絲雀發布的流量控制委託給Istio的VirtualService資源。
整合Istio的Rollout資源需要在strategy區段增加trafficRouting配置,指定要操作的Istio資源。canaryService與stableService分別對應金絲雀版本與穩定版本的Kubernetes Service,這兩個Service作為Istio路由規則的目標。
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: web-application-istio
namespace: production
spec:
replicas: 3
revisionHistoryLimit: 5
selector:
matchLabels:
app: web-service
template:
metadata:
labels:
app: web-service
spec:
containers:
- name: application
image: registry.company.com/web-service:2.0.0
ports:
- name: http
containerPort: 8080
strategy:
canary:
canaryService: web-service-canary
stableService: web-service-stable
trafficRouting:
istio:
virtualService:
name: web-service-routes
routes:
- primary
steps:
- setWeight: 5
- pause: {duration: 3m}
- setWeight: 10
- pause: {duration: 3m}
- setWeight: 20
- pause: {duration: 5m}
- setWeight: 40
- pause: {}
- setWeight: 60
- pause: {duration: 10m}
- setWeight: 80
- pause: {duration: 10m}
這個配置中的replicas僅設定為3,但透過Istio的流量分割能力,仍然可以實現5%這樣的精細流量控制。trafficRouting區段指定了VirtualService的名稱與要操作的路由規則,Argo Rollouts會在發布過程中動態更新這些規則。
Istio的VirtualService定義了流量路由邏輯。這個資源包含一個或多個HTTP路由規則,每條規則可以根據請求特徵將流量導向不同的目標服務。在金絲雀發布場景中,路由規則會動態調整穩定版本與金絲雀版本的流量權重。
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: web-service-routes
namespace: production
spec:
hosts:
- web-service.production.svc.cluster.local
- api.company.com
gateways:
- web-service-gateway
http:
- name: primary
match:
- uri:
prefix: /api
route:
- destination:
host: web-service-stable
port:
number: 80
weight: 100
- destination:
host: web-service-canary
port:
number: 80
weight: 0
timeout: 30s
retries:
attempts: 3
perTryTimeout: 10s
初始狀態下,VirtualService將100%流量導向穩定服務,金絲雀服務的權重為0。當Argo Rollouts開始金絲雀發布時,控制器會自動修改這些權重值以符合當前階段的目標。例如在第一階段,穩定服務權重會調整為95,金絲雀服務為5。
除了VirtualService,還需要建立兩個Kubernetes Service資源,分別對應穩定版本與金絲雀版本。這些Service透過不同的標籤選擇器指向對應的Pod集合。
apiVersion: v1
kind: Service
metadata:
name: web-service-stable
namespace: production
spec:
ports:
- name: http
port: 80
targetPort: http
protocol: TCP
selector:
app: web-service
# Argo Rollouts會自動管理這個標籤
# 指向穩定版本的Pod
---
apiVersion: v1
kind: Service
metadata:
name: web-service-canary
namespace: production
spec:
ports:
- name: http
port: 80
targetPort: http
protocol: TCP
selector:
app: web-service
# Argo Rollouts會自動管理這個標籤
# 指向金絲雀版本的Pod
Argo Rollouts控制器在發布過程中會動態管理Pod的標籤,確保穩定Service始終選擇穩定版本的Pod,金絲雀Service選擇金絲雀版本的Pod。這種自動化的標籤管理消除了手動協調的複雜性。
Gateway資源定義了從叢集外部進入的流量如何被路由。它指定了監聽的主機名稱、協定與連接埠,並與VirtualService配合工作完成完整的流量管理。
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
name: web-service-gateway
namespace: production
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- api.company.com
- port:
number: 443
name: https
protocol: HTTPS
hosts:
- api.company.com
tls:
mode: SIMPLE
credentialName: api-tls-certificate
整合Istio後的金絲雀發布流程與基礎模式類似,但流量控制更加精確。當執行promote指令時,Argo Rollouts不僅調整Pod副本數,還會更新VirtualService中的權重配置。Istio的Envoy代理會立即感知這些變更並相應地分配流量。
# 觀察VirtualService的權重變化
kubectl get virtualservice web-service-routes -n production -o yaml
# 輸出會顯示動態更新的權重
spec:
http:
- name: primary
route:
- destination:
host: web-service-stable
weight: 95
- destination:
host: web-service-canary
weight: 5
這種整合的優勢在於提供了更多控制選項。可以配置基於請求特徵的路由規則,例如將特定使用者群體的流量導向金絲雀版本,或根據地理位置進行流量分割。Istio的遙測功能也提供了更豐富的監控資料,包含請求延遲分布、成功率、重試次數等細緻指標。
# 進階路由規則範例
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: web-service-routes-advanced
namespace: production
spec:
hosts:
- api.company.com
http:
- name: beta-users
match:
- headers:
x-user-group:
exact: beta-testers
route:
- destination:
host: web-service-canary
weight: 100
- name: primary
route:
- destination:
host: web-service-stable
weight: 95
- destination:
host: web-service-canary
weight: 5
這個進階配置首先檢查請求標頭,如果使用者屬於beta測試群組,則將其流量完全導向金絲雀版本。其他使用者則按照5%的比例接收金絲雀流量。這種細粒度控制讓團隊能夠實施更複雜的發布策略,例如內部員工優先測試或特定客戶的專屬版本。
@startuml
!define PLANTUML_FORMAT svg
!theme _none_
skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100
actor "外部使用者" as user
component "Istio\nIngressGateway" as gateway
component "VirtualService" as vs
component "Stable Service" as stable_svc
component "Canary Service" as canary_svc
package "穩定版本Pod" {
component "Pod-1 v1" as pod1_stable
component "Pod-2 v1" as pod2_stable
component "Pod-3 v1" as pod3_stable
}
package "金絲雀版本Pod" {
component "Pod-1 v2" as pod1_canary
}
database "Argo Rollouts\n控制器" as rollouts
user -> gateway : HTTP請求
gateway -> vs : 路由決策
vs -> stable_svc : 95%流量
vs -> canary_svc : 5%流量
stable_svc -> pod1_stable : 負載均衡
stable_svc -> pod2_stable : 負載均衡
stable_svc -> pod3_stable : 負載均衡
canary_svc -> pod1_canary : 所有金絲雀流量
rollouts -up-> vs : 動態更新權重
rollouts -down-> stable_svc : 管理Pod標籤
rollouts -down-> canary_svc : 管理Pod標籤
note right of vs
精確的流量分割
支援請求特徵路由
即時權重調整
豐富的遙測資料
end note
note left of rollouts
協調發布流程
更新Istio規則
管理Pod生命週期
監控健康狀態
end note
@enduml自動化分析與智慧推進
手動推進金絲雀發布雖然提供了最大的控制權,但在頻繁發布的環境中會成為瓶頸。Argo Rollouts支援基於指標的自動化分析,能夠在達到設定的健康標準後自動推進到下一階段,或在偵測到異常時自動中止發布。
AnalysisTemplate資源定義了要評估的指標、查詢方式與成功標準。這些範本可以重複使用於多個Rollout,形成標準化的品質閘門。
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
name: success-rate-analysis
namespace: production
spec:
metrics:
- name: success-rate
interval: 1m
successCondition: result >= 0.95
failureLimit: 3
provider:
prometheus:
address: http://prometheus.monitoring.svc.cluster.local:9090
query: |
sum(rate(http_requests_total{
job="web-service",
status!~"5.."
}[5m]))
/
sum(rate(http_requests_total{
job="web-service"
}[5m]))
- name: avg-response-time
interval: 1m
successCondition: result < 500
failureLimit: 3
provider:
prometheus:
address: http://prometheus.monitoring.svc.cluster.local:9090
query: |
histogram_quantile(0.95,
sum(rate(http_request_duration_seconds_bucket{
job="web-service"
}[5m])) by (le)
) * 1000
這個AnalysisTemplate定義了兩個關鍵指標的評估邏輯。success-rate指標計算非5xx錯誤的請求比例,要求成功率不低於95%。avg-response-time指標查詢95百分位數的回應時間,要求不超過500毫秒。interval設定為1分鐘表示每分鐘執行一次查詢,failureLimit為3表示連續三次失敗後才判定分析失敗。
將AnalysisTemplate整合到Rollout資源需要在金絲雀策略中增加analysis區段,指定在哪些階段執行哪些分析範本。
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: web-application-auto
namespace: production
spec:
replicas: 5
selector:
matchLabels:
app: web-service
template:
metadata:
labels:
app: web-service
spec:
containers:
- name: application
image: registry.company.com/web-service:2.0.0
strategy:
canary:
steps:
- setWeight: 10
- pause: {duration: 2m}
- analysis:
templates:
- templateName: success-rate-analysis
- setWeight: 20
- pause: {duration: 2m}
- analysis:
templates:
- templateName: success-rate-analysis
- setWeight: 40
- pause: {duration: 5m}
- analysis:
templates:
- templateName: success-rate-analysis
args:
- name: service-name
value: web-service
- setWeight: 60
- pause: {duration: 5m}
- setWeight: 80
- pause: {duration: 5m}
每次到達analysis步驟時,Argo Rollouts會建立一個AnalysisRun資源實例,開始執行定義的指標查詢。如果所有指標在指定時間內都滿足成功條件,AnalysisRun標記為成功,發布自動推進到下一階段。如果任何指標連續失敗達到failureLimit,AnalysisRun標記為失敗,整個Rollout會自動中止並回滾。
# 觀察AnalysisRun的執行狀態
kubectl get analysisrun -n production
NAME STATUS AGE
web-application-auto-2-1 Running 45s
web-application-auto-2-2 Successful 5m
# 查看詳細的指標評估結果
kubectl describe analysisrun web-application-auto-2-1 -n production
AnalysisTemplate也支援從外部系統獲取指標,不限於Prometheus。可以整合Datadog、New Relic、Dynatrace等監控平台,甚至呼叫自訂的Webhook端點執行複雜的驗證邏輯。
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
name: custom-validation
namespace: production
spec:
metrics:
- name: custom-check
interval: 2m
successCondition: result == "pass"
failureLimit: 2
provider:
web:
url: https://validation.company.com/api/check
headers:
- key: Authorization
value: "Bearer {{args.api-token}}"
jsonPath: "{$.status}"
藍綠佈署策略
除了金絲雀發布,Argo Rollouts也支援藍綠佈署策略。這種模式同時維護兩個完整的應用程式環境,藍色環境執行當前穩定版本接收所有生產流量,綠色環境部署新版本但不接收流量。經過充分測試驗證後,透過切換Service的選擇器或Istio的路由規則,將所有流量瞬間從藍色環境遷移到綠色環境。
藍綠佈署的優勢在於切換過程極快且可以立即回滾。如果新版本出現問題,只需再次切換回藍色環境即可恢復服務。缺點是需要維護雙倍的資源,增加了基礎設施成本。
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: web-application-bluegreen
namespace: production
spec:
replicas: 5
revisionHistoryLimit: 2
selector:
matchLabels:
app: web-service
template:
metadata:
labels:
app: web-service
spec:
containers:
- name: application
image: registry.company.com/web-service:2.0.0
strategy:
blueGreen:
activeService: web-service-active
previewService: web-service-preview
autoPromotionEnabled: false
scaleDownDelaySeconds: 300
這個配置定義了藍綠佈署的關鍵參數。activeService指向當前接收生產流量的Service,previewService則用於測試新版本。autoPromotionEnabled設定為false表示需要手動批准才能切換,scaleDownDelaySeconds控制切換後舊版本Pod保留的時間,這段時間內可以快速回滾。
當更新Rollout觸發新的發布時,Argo Rollouts會建立新版本的所有Pod但不將其加入activeService。維運人員可以透過previewService存取新版本進行測試,確認無誤後執行promote指令完成切換。
# 推進藍綠佈署
kubectl argo rollouts promote web-application-bluegreen -n production
# 如果發現問題立即回滾
kubectl argo rollouts undo web-application-bluegreen -n production
最佳實踐與監控整合
成功實施Argo Rollouts需要結合完善的監控與告警體系。單純的自動化發布機制無法保證服務品質,必須配合即時的指標收集與異常偵測才能發揮最大價值。
建議在每個金絲雀階段收集全面的指標,包含應用程式層級的業務指標如訂單成功率、支付完成率,技術指標如錯誤率、回應時間、吞吐量,以及基礎設施指標如CPU使用率、記憶體消耗、網路延遲。這些指標應該在Grafana等視覺化工具中建立專屬的金絲雀發布儀表板,讓團隊能夠快速評估新版本的健康狀態。
告警規則應該涵蓋發布過程中的關鍵事件,例如金絲雀階段開始、分析失敗、自動中止、手動介入等。這些告警透過Slack、Microsoft Teams或PagerDuty等管道通知相關人員,確保問題能夠及時處理。
漸進式交付不僅是技術實踐,更是組織文化的體現。團隊需要建立對失敗的包容態度,將金絲雀發布視為早期發現問題的機會而非失敗的證明。定期回顧發布過程中遇到的問題與學到的經驗,持續優化發布策略與監控配置,形成不斷改進的良性循環。
Argo Rollouts為Kubernetes環境帶來了企業級的漸進式交付能力,透過宣告式的Rollout資源定義、靈活的發布策略編排、與Istio的深度整合以及自動化的指標分析,讓團隊能夠在保持快速迭代的同時確保服務穩定性。金絲雀發布與藍綠佈署等進階策略為不同場景提供了合適的解決方案,配合完善的監控告警體系,構建出可靠的持續交付流程。
