Lab 18 — Progressive Delivery với Argo Rollouts
Mục tiêu của Lab: Thay vì deploy version mới cho 100% người dùng ngay lập tức, chúng ta sẽ triển khai theo kiểu Canary Release: cho một phần nhỏ traffic đi vào version mới → kiểm tra → tăng traffic dần → nếu có lỗi thì rollback.
🎯 1. Mục tiêu
Sau Lab này, bạn sẽ:
- Hiểu Progressive Delivery và tại sao Rolling Update đôi khi chưa đủ an toàn.
- Hiểu Canary Release hoạt động như thế nào.
- Cài đặt và sử dụng Argo Rollouts.
- Thực hiện rollout theo từng bước
10% → 30% → 60% → 100%. - Biết cách pause, promote và abort một rollout.
- Hiểu cách kết hợp ArgoCD + Argo Rollouts trong production.
🤔 2. Vấn đề thực tế
Giả sử Todo App đang chạy:
Version v1
10 Pods
100% Traffic
Bạn vừa release v2.
Cách đơn giản nhất là:
v1
│
│ Deploy v2
▼
v2
100% Traffic
Nếu v2 có bug:
100% Users
│
▼
v2 ❌
│
▼
HTTP 500
Toàn bộ user đều bị ảnh hưởng.
Kubernetes RollingUpdate đã giúp chúng ta an toàn hơn:
v1 v1 v1 v1 v1
↓
v2 v1 v1 v1 v1
↓
v2 v2 v1 v1 v1
↓
v2 v2 v2 v1 v1
↓
v2 v2 v2 v2 v2
Nhưng vẫn có một vấn đề:
Kubernetes biết Pod đã
Ready, nhưng không thực sự biết version mới có đang trả HTTP 500, latency cao hay gây lỗi business hay không.
Argo Rollouts giải quyết bài toán này bằng cách cho phép kiểm soát quá trình rollout chi tiết hơn. Nó hỗ trợ Canary, Blue-Green, traffic shifting và có thể kết hợp metrics để quyết định promotion/rollback. ([Argo Rollouts][1])
🧠 3. Hiểu nhanh
3.1 Progressive Delivery là gì?
Thay vì:
v1 ───────────────► v2
0% 100%
ta làm:
v1 ────────────────►
│
├── 10% v2
│
├── 30% v2
│
├── 60% v2
│
└── 100% v2
Mỗi bước đều có thể:
Deploy
↓
Observe
↓
Healthy?
┌───────┴───────┐
Yes No
│ │
▼ ▼
Continue Abort
Đây chính là Progressive Delivery.
3.2 Canary Release là gì?
Canary nghĩa là:
Cho một lượng nhỏ traffic chạy vào version mới trước.
Ví dụ:
┌─── v1 ─── 90%
Users ───────┤
└─── v2 ─── 10%
Nếu v2 ổn:
v1 → 70%
v2 → 30%
Sau đó:
v1 → 40%
v2 → 60%
Cuối cùng:
v1 → 0%
v2 → 100%
Argo Rollouts cho phép định nghĩa các bước setWeight và pause để điều khiển quá trình này. ([Argo Rollouts][2])
🏗️ 4. Architecture
Trong Lab này, chúng ta sử dụng:
Git
│
▼
┌─────────────┐
│ ArgoCD │
└──────┬──────┘
│
▼
┌─────────────┐
│ Argo │
│ Rollouts │
└──────┬──────┘
│
┌───────┴────────┐
│ │
▼ ▼
Stable v1 Canary v2
90% 10%
│ │
└───────┬────────┘
│
▼
Users
Điểm quan trọng:
ArgoCD và Argo Rollouts có vai trò khác nhau.
ArgoCD
│
│ "Cluster phải giống Git"
▼
Kubernetes desired state
Argo Rollouts
│
│ "Version mới nên được release thế nào?"
▼
Progressive Delivery
Argo Rollouts là một Kubernetes controller riêng và không bắt buộc phải có ArgoCD. Tuy nhiên, hai công cụ kết hợp rất tốt trong GitOps. ([Argo Rollouts][3])
🛠️ 5. Chuẩn bị môi trường
Lab này giả sử bạn đã có:
- Kubernetes Cluster.
kubectl.- ArgoCD.
- Todo App hoặc một application đơn giản.
kubectlcó thể truy cập cluster.
Kiểm tra:
kubectl get nodes
Kiểm tra ArgoCD:
kubectl get pods -n argocd
📦 6. Cài đặt Argo Rollouts
6.1 Tại sao cần cài Argo Rollouts?
ArgoCD có nhiệm vụ:
Git → Kubernetes
Nhưng ArgoCD không phải công cụ chuyên xử lý:
10% → 30% → 60% → 100%
Argo Rollouts đảm nhận phần này.
Cài controller:
kubectl create namespace argo-rollouts
kubectl apply \
-n argo-rollouts \
-f https://raw.githubusercontent.com/argoproj/argo-rollouts/master/manifests/install.yaml
Kiểm tra:
kubectl get pods -n argo-rollouts
Kết quả mong đợi:
NAME READY STATUS
argo-rollouts-xxxxx 1/1 Running
🔧 7. Cài Argo Rollouts CLI
CLI giúp chúng ta quan sát rollout dễ hơn.
Ví dụ:
kubectl argo rollouts get rollout todo-app
Bạn có thể kiểm tra CLI:
kubectl argo rollouts version
Nếu command chưa tồn tại, hãy cài plugin
kubectl-argo-rolloutstheo hướng dẫn chính thức của Argo Rollouts.
🧪 8. Tạo Application
Để tập trung vào Progressive Delivery, chúng ta dùng một app đơn giản.
Tạo namespace:
kubectl create namespace progressive-demo
8.1 Version v1
Tạo file:
rollout.yaml
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: demo-app
namespace: progressive-demo
spec:
replicas: 5
selector:
matchLabels:
app: demo-app
template:
metadata:
labels:
app: demo-app
spec:
containers:
- name: demo-app
image: argoproj/rollouts-demo:blue
ports:
- containerPort: 8080
strategy:
canary:
steps:
- setWeight: 10
- pause: {}
- setWeight: 30
- pause: {}
- setWeight: 60
- pause: {}
- setWeight: 100
Tạo Service:
apiVersion: v1
kind: Service
metadata:
name: demo-app
namespace: progressive-demo
spec:
selector:
app: demo-app
ports:
- port: 80
targetPort: 8080
Apply:
kubectl apply -f rollout.yaml
kubectl apply -f service.yaml
👀 9. Kiểm tra Rollout
Chạy:
kubectl argo rollouts get rollout demo-app \
-n progressive-demo
Bạn sẽ thấy đại loại:
Name: demo-app
Namespace: progressive-demo
Status: Healthy
Strategy: Canary
Replicas:
Desired: 5
Current: 5
Updated: 5
Ready: 5
Version đầu tiên được deploy bình thường.
🚀 10. Deploy Version mới
Bây giờ giả sử team release:
v1 → v2
Thay image:
argoproj/rollouts-demo:blue
thành:
argoproj/rollouts-demo:yellow
Thực hiện:
kubectl argo rollouts set image \
demo-app \
demo-app=argoproj/rollouts-demo:yellow \
-n progressive-demo
Theo dõi:
kubectl argo rollouts get rollout demo-app \
-n progressive-demo \
-w
🔍 11. Observe Result
Rollout sẽ đi qua các bước:
Step 1
10% Canary
90% Stable
│
▼
PAUSE
Sau khi tiếp tục:
Step 2
30% Canary
70% Stable
│
▼
PAUSE
Tiếp tục:
Step 3
60% Canary
40% Stable
│
▼
PAUSE
Cuối cùng:
Step 4
100% Canary
0% Stable
Đây là điểm quan trọng nhất của Lab:
Version mới không được đưa lên toàn bộ hệ thống ngay lập tức.
▶️ 12. Promote Rollout
Khi kiểm tra thấy version mới ổn, chúng ta cho rollout tiếp tục.
kubectl argo rollouts promote \
demo-app \
-n progressive-demo
Kiểm tra:
kubectl argo rollouts get rollout demo-app \
-n progressive-demo
Nếu đang ở bước 30%, command này sẽ cho Rollout tiến tới bước tiếp theo.
🛑 13. Thử tình huống Production có lỗi
Đây mới là phần thú vị.
Giả sử:
v1 = Stable
v2 = Canary
Traffic:
v1 → 70%
v2 → 30%
Bạn phát hiện:
v2
├── HTTP 500 tăng
├── latency tăng
└── error rate tăng
Không nên tiếp tục rollout.
Abort:
kubectl argo rollouts abort \
demo-app \
-n progressive-demo
Kiểm tra:
kubectl argo rollouts get rollout demo-app \
-n progressive-demo
🧠 14. Điều gì vừa xảy ra?
Hãy nhìn lại:
Release v2
│
▼
┌─────────┐
│ 10% │
└────┬────┘
│
Observe
│
┌─────┴─────┐
│ │
Good Bad
│ │
▼ ▼
30% Abort
│ │
▼ ▼
60% Rollback
│
▼
100%
Đây chính là tư duy của Progressive Delivery:
Release nhỏ → quan sát → tăng dần → chỉ promote khi đủ an toàn.
🔄 15. Canary không chỉ là "chia Pod"
Đây là điểm người mới rất dễ nhầm.
Có hai khái niệm:
Cách đơn giản
5 Pods
v1: 4 Pods
v2: 1 Pod
Có vẻ giống:
80% v1
20% v2
Nhưng số Pod không đảm bảo chính xác tỷ lệ traffic.
Ví dụ:
v1: 4 Pods
v2: 1 Pod
không đồng nghĩa chắc chắn:
v1 = 80%
v2 = 20%
Traffic còn phụ thuộc vào cách Kubernetes Service, Ingress hoặc traffic router phân phối request.
Khi cần traffic shifting chính xác, Argo Rollouts có thể kết hợp với Ingress hoặc Service Mesh để điều khiển traffic giữa stable và canary. ([Argo Rollouts][4])
🌐 16. Traffic Routing
Production thường có kiến trúc:
Users
│
▼
Load Balancer
│
▼
Ingress / Mesh
│
┌────────┴────────┐
│ │
90% 10%
│ │
▼ ▼
Stable v1 Canary v2
Argo Rollouts có thể quản lý traffic routing thông qua các integration như NGINX, Istio, ALB và các traffic-routing plugin/Gateway API providers. ([Argo Rollouts][4])
Khi đó:
setWeight: 10
thực sự có ý nghĩa:
10% traffic → Canary
90% traffic → Stable
thay vì chỉ đơn giản là tạo ra 10% số Pod.
🔗 17. Kết hợp với ArgoCD
Đây là mục tiêu quan trọng nhất của Phase GitOps.
Thay vì:
kubectl argo rollouts set image ...
trong production, chúng ta đưa manifest vào Git.
Ví dụ:
gitops-repo/
│
├── apps/
│ └── todo/
│ ├── rollout.yaml
│ └── service.yaml
│
└── argocd/
└── todo-app.yaml
ArgoCD:
Git
│
│ Sync
▼
ArgoCD
│
▼
Rollout
│
├── 10%
├── 30%
├── 60%
└── 100%
Như vậy:
ArgoCD
│
│ Desired State
▼
Argo Rollouts
│
│ Progressive Delivery
▼
Kubernetes
ArgoCD quyết định "deploy cái gì".
Argo Rollouts quyết định "deploy version đó như thế nào".
📊 18. Production thực tế
Một hệ thống production tốt hơn sẽ có thêm monitoring:
Git
│
▼
ArgoCD
│
▼
Argo Rollouts
│
┌───────┴────────┐
│ │
Stable Canary
│ │
└───────┬────────┘
│
▼
Prometheus
│
▼
Error Rate
Latency
Request Rate
│
▼
Rollout
┌───────┴───────┐
│ │
Healthy Failed
│ │
Promote Abort
Ví dụ:
10% Canary
│
▼
Error Rate < 1% ?
│
┌─┴─────┐
Yes No
│ │
▼ ▼
30% Abort
Đây chính là bước tiến từ:
Manual Canary
sang:
Automated Canary Analysis
Argo Rollouts có thể truy vấn metrics từ các provider để đánh giá rollout và hỗ trợ promotion/rollback tự động. ([Argo Rollouts][1])
⚠️ 19. Những lỗi thường gặp
❌ 1. Nghĩ rằng Canary = chia số Pod
Không chính xác.
Pod ratio ≠ Traffic ratio
Nếu muốn kiểm soát traffic chính xác, cần traffic routing phù hợp. ([Argo Rollouts][4])
❌ 2. Canary nhưng không monitoring
Bạn có thể deploy:
10% v2
nhưng nếu không quan sát:
Error Rate
Latency
HTTP 5xx
CPU
Memory
Business Metrics
thì bạn cũng không biết v2 có thực sự tốt hay không.
Canary không thay thế Monitoring.
❌ 3. Canary quá lâu
Progressive Delivery không có nghĩa:
v2 chạy 2 tuần ở 10%
Argo Rollouts khuyến nghị dùng cho các rollout tương đối ngắn; tài liệu best practices đề cập khoảng 15–20 phút hoặc tối đa 1–2 giờ tùy use case. ([Argo Rollouts][3])
❌ 4. Không có Abort/Rollback Plan
Production cần trả lời được:
"Nếu v2 lỗi thì chúng ta quay lại v1 bằng cách nào?"
Không nên đến lúc production lỗi mới nghĩ câu này.
🧪 20. Exercise
Exercise 1 — Canary cơ bản
Thay đổi:
10% → 30% → 60% → 100%
thành:
5% → 25% → 50% → 100%
Quan sát Rollout.
Exercise 2 — Pause thủ công
Tạo:
steps:
- setWeight: 10
- pause: {}
- setWeight: 50
- pause: {}
- setWeight: 100
Sau đó:
kubectl argo rollouts promote demo-app
Quan sát từng bước.
Exercise 3 — Abort
Deploy version mới:
blue → yellow
Khi Rollout đang pause:
kubectl argo rollouts abort demo-app
Kiểm tra:
kubectl argo rollouts get rollout demo-app
Hãy trả lời:
Version nào đang phục vụ user sau khi abort?
Exercise 4 — GitOps
Đưa Rollout manifest vào Git repository.
Sau đó:
Git
↓
ArgoCD
↓
Argo Rollouts
↓
Canary
Mục tiêu là không còn phải deploy manifest bằng tay.
🧠 21. Tổng kết
Trước Lab:
Deploy v2
↓
100% Users
Sau Lab:
Deploy v2
↓
10%
↓
Observe
↓
30%
↓
Observe
↓
60%
↓
Observe
↓
100%
Nếu có lỗi:
Canary
↓
Detect Problem
↓
Abort
↓
Stable Version
Hãy nhớ 3 công cụ theo đúng vai trò:
┌───────────────┐
│ Git │
│ Source of │
│ Truth │
└───────┬───────┘
│
▼
┌───────────────┐
│ ArgoCD │
│ Deploy / Sync │
└───────┬───────┘
│
▼
┌───────────────┐
│ Argo Rollouts │
│ Progressive │
│ Delivery │
└───────┬───────┘
│
▼
Kubernetes
ArgoCD giúp bạn deploy đúng thứ đang có trong Git. Argo Rollouts giúp bạn release version mới một cách an toàn.
Đó là nền tảng để xây dựng một hệ thống GitOps Production thực tế.
All rights reserved
