Series ArgoCD Thực chiến #5: Đỉnh cao Canary Deployment – Thả "Chim hoàng yến" vào mỏ than

1. Nguồn gốc của "Chim hoàng yến" (Canary)

Ngày xưa, những người thợ mỏ thường mang theo một con chim hoàng yến xuống hầm. Nếu dưới hầm có rò rỉ khí độc, con chim sẽ chết trước tiên, báo hiệu cho những người thợ mỏ phải chạy thoát thân.

Trong lập trình, Canary Deployment cũng mang triết lý tương tự: Thay vì đẩy bản cập nhật v2.0 cho 100% người dùng, bạn chỉ đẩy nó cho 10% lượng khách hàng. 90% còn lại vẫn dùng bản v1.0 cũ. Bạn ngồi theo dõi log và phản hồi. Nếu 10% khách hàng này gặp lỗi (chim hoàng yến chết), bạn lập tức thu hồi v2.0 về mà không làm ảnh hưởng đến 90% khách hàng còn lại. Nếu mọi thứ trơn tru, bạn từ từ mở van lên 30%, 50% rồi 100%.

2. Argo Rollouts hoạt động như thế nào?

Argo Rollouts là một phần mở rộng (Custom Resource) cài thêm vào Kubernetes. Nó cung cấp một tài nguyên mới có tên là Rollout, thay thế hoàn toàn cho Deployment mặc định.

Cài đặt nhanh Argo Rollouts vào K8s:

kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml

(Tiện thể cài luôn plugin cho kubectl trên máy bạn để dễ thao tác):

curl -LO https://github.com/argoproj/argo-rollouts/releases/latest/download/kubectl-argo-rollouts-linux-amd64
chmod +x ./kubectl-argo-rollouts-linux-amd64
sudo mv ./kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts

3. Cấu hình kịch bản Canary cho hệ thống AFC

Trong thư mục chứa mã nguồn Helm Chart của bạn (mà ta đã làm ở Bài 3), hãy mở file templates/deployment.yaml lên.

Đổi chữ kind: Deployment thành kind: Rollout, và thêm khối strategy vào bên dưới. Nó sẽ trông giống như thế này:

apiVersion: argoproj.io/v1alpha1
kind: Rollout # Không dùng Deployment nữa
metadata:
  name: afc-core-api
spec:
  replicas: 5 # Đang chạy 5 Pods
  selector:
    matchLabels:
      app: afc-core-api
  template:
    # ... (Khai báo image và container y như cũ) ...
  
  # BÍ QUYẾT LÀ Ở ĐÂY: Chiến lược Canary
  strategy:
    canary:
      steps:
      # Bước 1: Đẩy 20% traffic (1 Pod mới, 4 Pod cũ)
      - setWeight: 20
      # Tạm dừng vô thời hạn để Dev test thực tế (chờ con người duyệt)
      - pause: {} 
      # Bước 2: Tăng lên 50% traffic
      - setWeight: 50
      # Tạm dừng 2 tiếng (tự động đi tiếp nếu không có lỗi)
      - pause: {duration: 2h}
      # Bước cuối cùng ngầm định là 100%

4. Triển khai kịch bản: Giây phút nghẹt thở

Bạn push file cấu hình này lên Git. ArgoCD cập nhật và cụm K8s bắt đầu áp dụng Rollout.

Tình huống thực chiến: Bạn đẩy một đoạn logic tính phí mới. Argo Rollouts sẽ phân tích cấu hình trên:

1. Nó tạo ra 1 Pod bản mới (chiếm 20% trên tổng số 5 Replicas) và giữ lại 4 Pod bản cũ.
2. Nó dừng lại ở lệnh pause: {}. Hệ thống đang ở trạng thái lơ lửng.

Ngay lúc này, chỉ có 20% số lượng request quẹt thẻ của hành khách là đập vào đoạn code mới của bạn. Bạn mở Terminal lên và dùng lệnh giám sát trực quan cực ngầu của Argo Rollouts:

kubectl argo rollouts get rollout afc-core-api --watch

Giao diện Console sẽ hiển thị rõ ràng cán cân: Bản cũ đang gánh 80%, bản mới đang gánh 20%.

Kịch bản A (Chim hoàng yến chết): Bạn xem Kibana/Elasticsearch và phát hiện ra 20% giao dịch mới này đang bị tính sai tiền. Đừng hoảng hốt! Bạn chỉ cần gõ lệnh sau để "quay xe":

kubectl argo rollouts abort afc-core-api

Hệ thống lập tức vứt bỏ Pod mới, đưa 100% traffic về lại bản cũ. Thảm họa đã được ngăn chặn trước khi lan rộng!

Kịch bản B (Mọi thứ hoàn hảo): Dữ liệu trả về rất đẹp, tính toán chính xác. Đã đến lúc bạn cấp phép cho hệ thống đi tiếp. Gõ lệnh:

kubectl argo rollouts promote afc-core-api

Rollouts sẽ tự động chuyển sang bước setWeight: 50 (chờ 2 tiếng tự động), và cuối cùng là đập bỏ hoàn toàn bản cũ, đưa bản mới lên thống trị 100%.

Tổng kết Series ArgoCD

Tuyệt vời! Qua 5 bài học, bạn đã lột xác hoàn toàn luồng CI/CD của hệ thống:

1. Bài 1 & 2: Làm quen với tư duy GitOps và cài đặt ArgoCD làm "bảo vệ" K8s.
2. Bài 3: Dùng Helm Chart đóng gói ứng dụng để ArgoCD phân phối đa môi trường.
3. Bài 4: Lắp mắt thần Image Updater để vòng lặp hoàn toàn khép kín tự động.
4. Bài 5: Chinh phục nghệ thuật Canary Deployment, loại bỏ rủi ro khi Release tính năng mới.

Sở hữu bộ khung này, bạn có thể tự tin đẩy code lên Production chiều thứ Sáu, rồi thảnh thơi đi uống bia mà không sợ cuối tuần bị gọi cháy máy vì sập server. Trách nhiệm của một Backend Engineer không chỉ là viết logic chạy đúng, mà còn là thiết kế một môi trường vận hành an toàn cho mã nguồn đó.