บทนำ: Deployment Strategy ใน Kubernetes

Deployment Strategy เป็นวิธีการปรับใช้แอปพลิเคชันใหม่หรือเวอร์ชันอัปเดตของแอปพลิเคชันบน Kubernetes Cluster อย่างปลอดภัยและมีประสิทธิภาพ ในงาน DevOps สมัยใหม่ เราต้องการให้การทำให้ใช้งานได้ใหม่ เกิดขึ้นโดยไม่มีการหยุดชะงัก (Zero-Downtime Deployment)

การเลือกใช้ Deployment Strategy ที่ถูกต้องจะช่วยลดความเสี่ยง ลดเวลา Rollback และรักษาความสำเร็จและเสถียรภาพของบริการของคุณ

1. Rolling Update Strategy

Rolling Update เป็นกลยุทธ์ default ใน Kubernetes ซึ่งแทนที่ Pod เก่าด้วย Pod ใหม่ทีละอันในลำดับที่ค่อยเป็นค่อยไป

ข้อดีของ Rolling Update:

• ไม่มีการหยุดชะงักของบริการ (Zero-Downtime)
• ใช้ทรัพยากรเดียวกัน ไม่ต้องเพิ่มทรัพยากรเพิ่มเติม
• Rollback ง่าย หากเกิดปัญหา
• ติดตั้งใช้งานค่อยเป็นค่อยไป ลดความเสี่ยง

ข้อเสียของ Rolling Update:

• การอัปเดตใช้เวลานาน
• ระหว่างการอัปเดต คุณจะมีเวอร์ชันแอปพลิเคชันหลาย version รันพร้อมกัน
• ต้องพิจารณา Database Migration หากมี

ตัวอย่างการตั้งค่า Rolling Update:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # Pod เพิ่มเติมสูงสุด 1 ตัว
      maxUnavailable: 1  # Pod ที่ไม่พร้อมใช้งานสูงสุด 1 ตัว
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:v2
        ports:
        - containerPort: 8080

2. Blue-Green Deployment Strategy

Blue-Green Deployment เป็นกลยุทธ์ที่รักษา 2 สภาพแวดล้อมการผลิตที่เหมือนกันทั้งหมด (Blue = เวอร์ชันปัจจุบัน, Green = เวอร์ชันใหม่) และสลับการรับส่งข้อมูลระหว่างพวกเขาทันที

ข้อดีของ Blue-Green:

• Rollback ได้ในทันที โดยเพียงสลับเป็น Blue
• ทำการทดสอบเต็มแบบบน Green ก่อนเปิดให้ traffic จริง
• ไม่มีเวอร์ชันหลายตัวรันพร้อมกัน
• การเปลี่ยนแปลงทันที (Instant Switch)

ข้อเสียของ Blue-Green:

• ต้องใช้ทรัพยากรเพิ่มเติมมาก (คิดเป็น 2 เท่า)
• Database เดียวกัน อาจเกิดปัญหา compatibility
• การบำรุงรักษาระบบ Deployment เพิ่มขึ้น

3. Canary Deployment Strategy

Canary Deployment นำเสนอเวอร์ชันใหม่ให้กับชุดย่อยของผู้ใช้ก่อน (เช่น 5% ของ traffic) แล้วค่อยๆ เพิ่มจำนวนจนถึง 100%

ข้อดีของ Canary:

• ลดความเสี่ยงจากการปล่อยเวอร์ชันใหม่
• ทำการเฝ้าดู (Monitor) ประสิทธิภาพจริง ก่อนปล่อยเต็มที่
• Rollback ได้อย่างรวดเร็วหากเกิดปัญหา
• ใช้ทรัพยากรเพิ่มเติมน้อย

ข้อเสียของ Canary:

• ต้องมี Monitoring เพื่อติดตามประสิทธิภาพ
• การปล่อยใช้เวลานาน
• ต้องเข้าใจเกี่ยวกับ Load Balancing

ตัวอย่าง Canary ด้วย Istio:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: my-app
spec:
  hosts:
  - my-app
  http:
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        host: my-app
        subset: v1
      weight: 95  # 95% ไปเวอร์ชันเก่า
    - destination:
        host: my-app
        subset: v2
      weight: 5   # 5% ไปเวอร์ชันใหม่

เลือก Deployment Strategy ที่เหมาะสม

เลือก Rolling Update: เมื่อแอปพลิเคชันของคุณสามารถทนต่อ backward compatibility ได้ดี และไม่จำเป็นต้อง Rollback อย่างรวดเร็ว

เลือก Blue-Green: เมื่อคุณต้องการ Rollback ในทันที และมีทรัพยากรพอสำหรับรัน 2 environment พร้อมกัน

เลือก Canary: เมื่อต้องการลดความเสี่ยงและมี Monitoring ที่ดี เหมาะสำหรับ production ขนาดใหญ่

สรุป

ทั้ง 3 Deployment Strategy มีข้อดีและข้อเสีย คุณต้องเลือกตามความเหมาะสมของสถานการณ์ของคุณ บน Cloud VPS ของ ผู้ให้บริการโฮสติ้ง คุณสามารถใช้ Kubernetes ที่มีความเสถียร และปล่อยแอปพลิเคชันของคุณด้วยความมั่นใจ