Argo CD + Argo Rollouts ทำ Canary Deployment แบบค่อยๆ เปลี่ยน Traffic

ในบทความนี้ เราจะศึกษาวิธีการใช้งาน Argo CD ร่วมกับ Argo Rollouts เพื่อทำการ Canary Deployment บนโครงสร้าง Kubernetes ที่วิ่งบน Cloud VPS ของ ผู้ให้บริการโฮสติ้ง (DE) แบบค่อยๆ เปลี่ยน Traffic ไปยังเวอร์ชันใหม่ของแอปพลิเคชัน

บทนำ: ความสำคัญของ Canary Deployment

การอัปเดตแอปพลิเคชันเป็นส่วนสำคัญของการดูแลรักษา แต่การเปลี่ยนเวอร์ชันอย่างกะทันหันมักนำมาซึ่งความเสี่ยง Canary Deployment ช่วยลดความเสี่ยงเหล่านี้โดยการปล่อยเวอร์ชันใหม่ให้บริการเพียงส่วนหนึ่งของผู้ใช้ก่อน

Canary Deployment คืออะไร

1. เวอร์ชันเก่า (Stable): เวอร์ชันปัจจุบันที่ให้บริการ 100% ของผู้ใช้
2. ปล่อย Canary: ปล่อยเวอร์ชันใหม่ให้เซิร์ฟเวอร์ 5-10% เท่านั้น
3. ตรวจสอบ (Monitoring): สังเกตการณ์เพื่อหาข้อบกพร่อง
4. ค่อยๆ เพิ่ม (Gradual Rollout): ถ้าเสถียร ให้เพิ่มเป็น 25% → 50% → 100%
5. เสร็จสิ้น (Complete): เวอร์ชันใหม่ให้บริการ 100% ของผู้ใช้

ทำไมต้องใช้ Canary Deployment

• ลดความเสี่ยง: ส่วนหนึ่งของผู้ใช้ได้รับความเสี่ยง ไม่ใช่ทั้งหมด
• ระบุปัญหาเร็ว: เมื่อเกิดข้อบกพร่อง ตรวจพบได้ทันที
• กู้คืนได้เร็ว: สามารถสลับกลับไปใช้เวอร์ชันเก่าได้ทันที
• สนับสนุน Continuous Deployment: ช่วยให้ release cycle เร็วขึ้นด้วยความเสี่ยงที่ลดลง

Argo Rollouts คืออะไร

Argo Rollouts เป็น Kubernetes controller ที่ออกแบบมาเพื่ออำนวยความสะดวกในการทำ advanced deployment strategies อย่างเช่น Canary, Blue-Green, และ Rolling Updates

• Rollout Resource: รีซอร์สที่คล้ายกับ Deployment แต่มีความสามารถมากกว่า
• Rollout Controller: ควบคุมการปล่อยเวอร์ชันใหม่ตามกลยุทธ์ที่กำหนด
• AnalysisTemplate: สำหรับประเมินความสำเร็จโดยอัตโนมัติ
• TrafficManagement Integration: รองรับ Istio, Nginx Ingress, AWS ALB

การติดตั้ง Argo Rollouts

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

หรือผ่าน Helm:

helm repo add argo https://argoproj.github.io/argo-helm
helm install argo-rollouts argo/argo-rollouts -n argo-rollouts --create-namespace

Rollout Resource vs Deployment

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:v1
  strategy:
    canary:
      steps:
      - setWeight: 10
      - pause: {}
      - setWeight: 25
      - pause: {duration: 5m}
      - setWeight: 50
      - pause: {duration: 5m}

การตั้งค่า Canary Strategy

strategy:
  canary:
    canaryService: myapp-canary
    stableService: myapp-stable
    steps:
    - setWeight: 5
    - pause: {duration: 10m}
    - setWeight: 10
    - pause: {duration: 5m}
    - setWeight: 25
    - pause: {duration: 5m}
    - setWeight: 50
    - pause: {duration: 5m}
    - setWeight: 100

AnalysisTemplate สำหรับการประเมินอัตโนมัติ

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  metrics:
  - name: success-rate
    query: sum(rate(http_requests_total{status=~"2.."}[5m])) / sum(rate(http_requests_total[5m]))
    thresholds:
      successCriteria: ">= 0.95"
      failureCriteria: "< 0.90"
    interval: 1m
    count: 5

การจัดการ Traffic ด้วย Istio

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: myapp
spec:
  strategy:
    canary:
      trafficManagement:
        istio:
          virtualService:
            name: myapp
      canaryService: myapp-canary
      stableService: myapp-stable
      steps:
      - setWeight: 10
      - pause: {duration: 5m}
      - setWeight: 50
      - pause: {duration: 5m}
      - setWeight: 100

การจัดการ Traffic ด้วย Nginx Ingress

strategy:
  canary:
    trafficManagement:
      nginx:
        stableIngress: myapp-stable
    steps:
    - setWeight: 10
    - pause: {duration: 5m}
    - setWeight: 50
    - pause: {duration: 5m}
    - setWeight: 100

การรวม Argo CD กับ Argo Rollouts

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/example/repo
    targetRevision: main
    path: apps/myapp
  destination:
    server: https://kubernetes.default.svc
    namespace: default
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

กลยุทธ์การ Rollback

# ยกเลิกการปล่อยเวอร์ชันใหม่ทันที
kubectl argo rollouts abort rollout/myapp

# เปลี่ยนกลับไปใช้ revision เก่า
kubectl argo rollouts undo rollout/myapp --to-revision=1

Best Practices สำหรับ Canary Deployment

1. เริ่มต้นด้วยเปอร์เซนต์เล็กๆ: เริ่มที่ 5-10%
2. ใช้ค่า timeout ที่เหมาะสม: กำหนดเวลาการ pause ให้นานพอ
3. จัดตั้ง monitoring และ alerting: ต้องมีระบบแจ้งเตือน
4. ทดสอบ Analysis rules ก่อนเผยแพร่: ตรวจสอบว่า query ถูกต้อง
5. ใช้สม่ำเสมอกับทุก release: ทำให้เป็นส่วนหนึ่งของ process
6. บันทึกและวิเคราะห์: เก็บบันทึกของการปล่อยเวอร์ชันใหม่
7. ทำให้อัตโนมัติ: ใช้ Argo CD เพื่อให้เป็นไปโดยอัตโนมัติ

การแก้ไขปัญหา (Troubleshooting)

ปัญหา: Rollout ติดอยู่ที่ขั้นตอน pause

kubectl argo rollouts resume rollout/myapp

ปัญหา: Analysis Template ล้มเหลว

kubectl get analysisrun
kubectl describe analysisrun <name>

การติดตั้งบน Cloud VPS ของ ผู้ให้บริการโฮสติ้ง

ผู้ให้บริการโฮสติ้ง Cloud VPS (https://de.co.th/cloud-vps) ให้ความยืดหยุ่นและความปลอดภัยสูง ทำให้เหมาะสำหรับการรัน production Kubernetes cluster พร้อม Argo Rollouts

1. ติดตั้ง Kubernetes cluster บน Cloud VPS
2. ติดตั้ง Argo CD สำหรับการจัดการ GitOps
3. ติดตั้ง Argo Rollouts
4. ติดตั้ง Istio หรือ Nginx Ingress เพื่อจัดการ traffic
5. ติดตั้ง Prometheus สำหรับ monitoring

สรุป

Argo CD ร่วมกับ Argo Rollouts ช่วยให้การปล่อยเวอร์ชันใหม่ของแอปพลิเคชันเป็นไปอย่างปลอดภัยและมีประสิทธิภาพ Canary Deployment ทำให้สามารถทดสอบเวอร์ชันใหม่กับกลุ่มเล็กๆ ของผู้ใช้ก่อน แล้วค่อยๆ เพิ่มไปยังผู้ใช้ทั้งหมด

การเลือกใช้ Cloud VPS ของ ผู้ให้บริการโฮสติ้ง (https://de.co.th/cloud-vps) เป็นรากฐานที่มั่นคงสำหรับการจัดการ modern applications ในสภาวะ production