Rollback Strategy #

Deployment yang gagal adalah sesuatu yang akan terjadi — pertanyaannya bukan apakah, tapi kapan. Seberapa cepat dan semudah apa kamu bisa rollback saat itu terjadi adalah perbedaan antara insiden yang berlangsung 5 menit vs 2 jam. Kubernetes menyediakan mekanisme rollback yang cukup solid, tapi ada nuansa penting yang perlu dipahami agar rollback benar-benar efektif saat dibutuhkan.

Rollback Deployment di Kubernetes #

Kubernetes menyimpan riwayat deployment dalam bentuk ReplicaSet lama. Setiap kali Deployment di-update, ReplicaSet versi sebelumnya dipertahankan (dengan replicas=0) untuk keperluan rollback.

# Lihat riwayat rollout
kubectl rollout history deployment/api -n production

# Output:
# REVISION  CHANGE-CAUSE
# 1         deploy v1.0.0
# 2         deploy v1.1.0 - add user auth
# 3         deploy v2.0.0 - rewrite login flow

# Rollback ke revision sebelumnya (dari 3 ke 2)
kubectl rollout undo deployment/api -n production

# Rollback ke revision spesifik
kubectl rollout undo deployment/api --to-revision=1 -n production

# Pantau progress rollback
kubectl rollout status deployment/api -n production

# Lihat detail tiap revision
kubectl rollout history deployment/api --revision=2 -n production

# Output:
# Pod Template:
#   Labels: app=api, version=1.1.0
#   Containers:
#     api:
#       Image: my-api:v1.1.0
#       ...

revisionHistoryLimit #

Berapa banyak ReplicaSet lama yang disimpan ditentukan oleh revisionHistoryLimit:

spec:
  revisionHistoryLimit: 5    # simpan 5 revision terakhir (default: 10)

Dengan revisionHistoryLimit: 3:

  Revision 1: ReplicaSet (0 replicas) ← akan dihapus saat revision 5 dibuat
  Revision 2: ReplicaSet (0 replicas)
  Revision 3: ReplicaSet (0 replicas)
  Revision 4: ReplicaSet (0 replicas)
  Revision 5: ReplicaSet (4 replicas) ← aktif

  Buat revision 6 → Revision 1 dihapus, hanya 3, 4, 5 yang tersisa

Implikasi:
  → Tidak bisa rollback ke revision yang sudah terhapus
  → Set nilainya sesuai kebutuhan rollback kamu
  → Terlalu besar: banyak ReplicaSet lama memenuhi cluster
  → Terlalu kecil: tidak bisa rollback lebih jauh

Rollback Otomatis dengan readinessProbe dan progressDeadlineSeconds #

Kubernetes bisa mendeteksi deployment yang gagal dan berhenti maju (tapi tidak otomatis rollback):

spec:
  progressDeadlineSeconds: 300    # deployment harus selesai dalam 5 menit
  template:
    spec:
      containers:
      - name: api
        readinessProbe:
          httpGet:
            path: /health/ready
            port: 8080
          failureThreshold: 3     # 3 kali gagal = Pod tidak Ready

# Jika Pod baru tidak pernah Ready dalam progressDeadlineSeconds:
# Deployment status berubah ke "Failed"
kubectl get deployment api -n production
# AVAILABLE = 0 atau kurang dari expected

# Rollback manual diperlukan:
kubectl rollout undo deployment/api -n production

Untuk rollback otomatis berbasis metrik (bukan hanya health check), gunakan Argo Rollouts atau Flagger yang menganalisis Prometheus metrics.

Skenario Rollback dan Kompleksitasnya #

Skenario 1: Bug di Kode (Paling Mudah) #

# Symptom: error rate naik, latensi tinggi
# Tidak ada perubahan database schema

kubectl rollout undo deployment/api -n production
# Selesai dalam 2-5 menit, data tidak terpengaruh

Skenario 2: Setelah Database Migration Additive #

# Migration: tambah kolom baru di v2

# Rollback aplikasi ke v1:
kubectl rollout undo deployment/api -n production
# v1 tidak menggunakan kolom baru → tidak ada masalah
# Kolom baru di database tidak ada yang isi → tidak masalah

# Opsional: hapus kolom yang tidak digunakan
# (tunggu sampai dipastikan tidak perlu rollback lagi)

Skenario 3: Setelah Migration Destructive (Paling Sulit) #

# Migration: hapus kolom user_name (yang digunakan v1)
# Lalu bug ditemukan di v2

# Rollback aplikasi ke v1:
kubectl rollout undo deployment/api -n production
# v1 mencoba baca user_name yang sudah tidak ada → ERROR

# Opsi 1: Jalankan reverse migration (buat ulang kolom)
kubectl apply -f reverse-migration-job.yaml

# Opsi 2: Lanjutkan dengan v2 dan fix bug (forward fix)
# Lebih baik daripada reverse migration yang berisiko data loss
kubectl set image deployment/api api=my-api:v2.1-hotfix -n production

# Ini adalah alasan mengapa migration destructive harus TIDAK dilakukan
# bersamaan dengan deployment utama — tunggu sampai benar-benar stabil

Rollback untuk Blue/Green #

# Rollback Blue/Green sangat sederhana:
# Kembalikan selector Service ke blue

kubectl patch service api-service -n production \
  -p '{"spec":{"selector":{"version":"blue"}}}'

# Selesai dalam hitungan detik
# Tidak ada Pod yang perlu restart

Rollback untuk Canary (Argo Rollouts) #

# Abort canary dan rollback ke stable
kubectl argo rollouts abort api -n production

# Rollback manual
kubectl argo rollouts undo api -n production

# Lihat status
kubectl argo rollouts get rollout api -n production

Checklist Rollback yang Efektif #

Sebelum deployment (persiapan):
  □ revisionHistoryLimit diset ke nilai yang wajar (minimal 5)
  □ Change cause di-annotate untuk setiap deployment
  □ readinessProbe dan progressDeadlineSeconds dikonfigurasi
  □ Runbook rollback sudah ada dan diketahui tim
  □ Database migration strategy sudah diperhitungkan

Saat deployment (monitoring):
  □ Pantau error rate dan latensi selama rolling update
  □ Perhatikan kubectl rollout status
  □ Alert Prometheus untuk deteksi masalah otomatis

Saat perlu rollback (eksekusi):
  □ Identifikasi jenis rollback: code only vs code+db
  □ Jika code only: kubectl rollout undo
  □ Jika ada migration destructive: siapkan reverse migration
  □ Komunikasikan ke tim dan stakeholder
  □ Monitor setelah rollback untuk konfirmasi masalah teratasi

Setelah rollback (investigasi):
  □ Root cause analysis
  □ Perbaiki sebelum deploy ulang
  □ Pertimbangkan test coverage yang lebih baik

Ringkasan #

kubectl rollout undo adalah rollback paling cepat — kembali ke ReplicaSet versi sebelumnya dalam hitungan menit; tidak perlu push image baru.
revisionHistoryLimit menentukan seberapa jauh bisa rollback — default 10; set sesuai kebutuhan; terlalu kecil membatasi opsi rollback.
Rollback setelah migration destructive sangat berbahaya — selalu pisahkan migration destructive dari deployment utama; tunggu versi baru benar-benar stabil sebelum hapus kolom lama.
Blue/Green memberikan rollback tercepat — switch selector Service tidak memerlukan Pod restart; rollback dalam hitungan detik.
progressDeadlineSeconds mendeteksi deployment stuck — tapi tidak rollback otomatis; Argo Rollouts atau Flagger untuk rollback otomatis berbasis metrik.
Siapkan runbook rollback sebelum insiden — di tengah insiden bukan waktu yang tepat untuk mencari tahu cara rollback; prosedur harus sudah ada dan dilatih.

← Sebelumnya: Database Migration Strategy Berikutnya: GitOps →