Blue/Green Deployment #

Blue/Green deployment menjalankan dua environment identik secara bersamaan — satu melayani traffic production (blue), satu lagi berisi versi baru yang belum menerima traffic (green). Saat green sudah ditest dan siap, traffic dipindah sekaligus. Jika ada masalah, rollback adalah pekerjaan satu perintah yang selesai dalam hitungan detik. Harganya: dua kali resource selama proses.

Konsep dan Mekanisme #

State awal (blue aktif):

  Internet → Load Balancer
                  │
                  ▼
           Service (selector: version=blue)
                  │
          ┌───────┴───────┐
       [blue-1]        [blue-2]     ← v1, menerima traffic
       [blue-3]        [blue-4]

  [green-1] [green-2] [green-3] [green-4]   ← v2, tidak ada traffic

Setelah switch (green aktif):

  Internet → Load Balancer
                  │
                  ▼
           Service (selector: version=green)
                  │
          ┌───────┴───────┐
       [green-1]      [green-2]     ← v2, menerima traffic
       [green-3]      [green-4]

  [blue-1] [blue-2] [blue-3] [blue-4]   ← v1, standby untuk rollback

Perpindahan traffic terjadi dengan mengubah selector Service — operasi yang atomik dan berlaku instan.

Implementasi dengan Service Selector #

# Deployment Blue (versi current/v1)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-blue
  namespace: production
spec:
  replicas: 4
  selector:
    matchLabels:
      app: api
      version: blue
  template:
    metadata:
      labels:
        app: api
        version: blue     # ← label ini yang dipilih Service
    spec:
      containers:
      - name: api
        image: my-api:v1

---
# Deployment Green (versi baru/v2)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-green
  namespace: production
spec:
  replicas: 4
  selector:
    matchLabels:
      app: api
      version: green
  template:
    metadata:
      labels:
        app: api
        version: green
    spec:
      containers:
      - name: api
        image: my-api:v2

---
# Service yang mengarahkan traffic ke versi aktif
apiVersion: v1
kind: Service
metadata:
  name: api-service
  namespace: production
spec:
  selector:
    app: api
    version: blue      # ← ganti ke "green" untuk switch traffic
  ports:
  - port: 80
    targetPort: 8080

# Switch traffic dari blue ke green (satu perintah)
kubectl patch service api-service -n production \
  -p '{"spec":{"selector":{"app":"api","version":"green"}}}'

# Verifikasi switch berhasil
kubectl get endpoints api-service -n production
# Harus menunjukkan IP Pod dari Deployment green

# Rollback instan ke blue jika ada masalah
kubectl patch service api-service -n production \
  -p '{"spec":{"selector":{"app":"api","version":"blue"}}}'

Implementasi dengan Ingress #

Untuk aplikasi yang diekspos via Ingress, switch bisa dilakukan dengan mengubah backend Service di Ingress, atau dengan menggunakan dua Service dan memindahkan selector Ingress.

# Dua Service — satu per versi
apiVersion: v1
kind: Service
metadata:
  name: api-blue
spec:
  selector:
    app: api
    version: blue
  ports:
  - port: 80
    targetPort: 8080

---
apiVersion: v1
kind: Service
metadata:
  name: api-green
spec:
  selector:
    app: api
    version: green
  ports:
  - port: 80
    targetPort: 8080

---
# Ingress mengarahkan ke Service yang aktif
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-blue       # ← ganti ke api-green untuk switch
            port:
              number: 80

# Switch via patch Ingress
kubectl patch ingress api-ingress -n production \
  --type=json \
  -p='[{"op":"replace","path":"/spec/rules/0/http/paths/0/backend/service/name","value":"api-green"}]'

Pre-deployment Testing di Green Environment #

Sebelum memindahkan traffic production ke green, lakukan testing secara langsung ke Deployment green tanpa mempengaruhi production:

# Port-forward langsung ke Deployment green untuk testing manual
kubectl port-forward deployment/api-green 8080:8080 -n production
curl http://localhost:8080/health
curl http://localhost:8080/api/users

# Atau jalankan automated smoke test via Job
kubectl apply -f - <<EOF
apiVersion: batch/v1
kind: Job
metadata:
  name: green-smoke-test
  namespace: production
spec:
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: smoke-test
        image: my-smoke-test:latest
        env:
        - name: TARGET_HOST
          value: "api-green.production.svc.cluster.local"
        - name: EXPECTED_VERSION
          value: "v2"
EOF

# Tunggu job selesai
kubectl wait job/green-smoke-test --for=condition=complete -n production --timeout=5m

Manajemen Sumber Daya dan Biaya #

Blue/Green membutuhkan dua kali resource selama proses berlangsung. Beberapa strategi untuk mengelola biaya:

Strategi 1: Scale down blue setelah switch dikonfirmasi

  # Setelah traffic pindah ke green dan stabil selama N jam:
  kubectl scale deployment api-blue --replicas=1 -n production
  # Tetap jaga 1 Pod sebagai minimal untuk rollback cepat

Strategi 2: Jadwal pembersihan otomatis

  # Buat CronJob yang scale down blue setelah X jam
  # atau gunakan ArgoCD / Flux untuk manage lifecycle

Strategi 3: Ephemeral green environment

  # Buat green hanya saat deployment berlangsung
  # Hapus deployment lama setelah konfirmasi stabil
  # Tidak ideal karena proses buat baru butuh waktu

Kapan Blue/Green Tepat Digunakan #

Blue/Green cocok untuk:
  ✓ Perubahan besar yang butuh rollback instan jika gagal
  ✓ Rilis yang harus bisa ditest di production environment sebelum menerima traffic
  ✓ Compliance requirement: versi sebelumnya harus tersedia sampai versi baru
    divalidasi sepenuhnya
  ✓ Database migration yang tidak backward-compatible
    (dengan maintenance window singkat)
  ✓ Tim yang butuh confidence tinggi sebelum fully commit ke versi baru

Blue/Green kurang tepat jika:
  ✗ Cluster resource sudah mendekati kapasitas
  ✗ Deployment terjadi sangat sering (beberapa kali sehari)
    → overhead resource kurang efisien
  ✗ Perubahan kecil (hotfix, config update) → Rolling lebih simpel
  ✗ Stateful aplikasi dengan session affinity yang kompleks

Ringkasan #

  • Traffic switch via Service selector — satu perintah, berlaku instan — patch spec.selector Service dari version: blue ke version: green; rollback adalah perintah yang sama dengan arah sebaliknya.
  • Test green sebelum switch — port-forward langsung ke Deployment green atau jalankan smoke test Job ke Service green tanpa mempengaruhi traffic production.
  • Scale down blue setelah konfirmasi — tidak perlu 2x resource selamanya; setelah green stabil, scale blue ke minimal 1 untuk keep rollback capability tanpa biaya penuh.
  • Dua pendekatan switch — via Service selector (simpel) atau via Ingress backend (lebih fleksibel untuk HTTP routing yang kompleks).
  • Cocok untuk perubahan besar — nilai rollback instan paling terasa untuk rilis berisiko tinggi; untuk hotfix dan perubahan kecil, Rolling sudah cukup.
  • Stateful workload perlu perhatian ekstra — pastikan session handling dan database compatibility sudah dipertimbangkan sebelum switch traffic.

← Sebelumnya: Rolling Update   Berikutnya: Canary Deployment →

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact