Recreate #

Recreate adalah strategi deployment paling sederhana: matikan semua Pod versi lama, lalu buat semua Pod versi baru. Ada downtime — periode singkat di mana tidak ada Pod yang berjalan. Ini bukan pilihan yang lazim untuk production, tapi ada skenario di mana Recreate bukan hanya dapat diterima, tapi justru lebih aman dari pendekatan zero-downtime. Artikel ini membahas kapan dan bagaimana menggunakannya dengan benar.

Cara Kerja Recreate #

Deployment dengan strategy: Recreate

  Kondisi awal:
  [v1] [v1] [v1] [v1]   ← 4 Pod berjalan, melayani traffic

  kubectl apply (image: v2)

  Langkah 1: Kubernetes set replicas ReplicaSet v1 → 0
  [terminate] [terminate] [terminate] [terminate]
  → Pod v1 menyelesaikan request yang sedang diproses (graceful shutdown)
  → Pod v1 dihapus

  [DOWNTIME — tidak ada Pod]

  Langkah 2: Kubernetes buat ReplicaSet v2 dengan replicas = 4
  [starting] [starting] [starting] [starting]
  → Pod v2 dimulai dan melewati readiness probe

  Kondisi akhir:
  [v2] [v2] [v2] [v2]   ← 4 Pod berjalan

Konfigurasi #

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
  namespace: production
spec:
  replicas: 4
  strategy:
    type: Recreate    # ← tidak ada field rollingUpdate
  template:
    spec:
      containers:
      - name: api
        image: my-api:v2
      terminationGracePeriodSeconds: 30   # tunggu sampai 30 detik untuk graceful shutdown

Kapan Recreate Menjadi Pilihan yang Tepat #

Kasus 1: Perubahan Database Schema yang Tidak Backward-Compatible #

Ini adalah kasus paling umum di mana Recreate atau setidaknya maintenance window diperlukan.

Skenario: Rename kolom database

  v1 aplikasi: SELECT user_name FROM users
  v2 aplikasi: SELECT username FROM users   (kolom di-rename)

  Dengan Rolling Update (v1 dan v2 berjalan bersamaan):
    v1 Pod: query user_name → berhasil (kolom masih ada)
    v2 Pod: query username  → GAGAL (kolom belum ada)

  Dengan pendekatan yang benar:
    1. Database migration: tambah kolom username, copy data dari user_name
    2. Deploy v2 (v2 bisa baca username, v1 masih baca user_name → keduanya jalan)
    3. Setelah semua Pod v1 hilang, hapus kolom user_name

Untuk migration yang benar-benar tidak kompatibel (tidak bisa expand-contract), perlu maintenance window dengan Recreate atau Blue/Green.

Kasus 2: Perubahan Fundamental pada Shared State #

Skenario: Ganti format serialisasi message queue

  v1: menggunakan JSON untuk message format
  v2: menggunakan Protocol Buffers

  Dengan Rolling Update:
    v1 Producer → JSON message → v2 Consumer GAGAL (tidak bisa parse JSON)
    v2 Producer → Protobuf message → v1 Consumer GAGAL (tidak bisa parse Protobuf)

  Solusi: Recreate dengan maintenance window
    1. Stop semua consumer (scale to 0)
    2. Drain message queue
    3. Deploy v2 semua sekaligus
    4. Resume operation

Kasus 3: Aplikasi yang Tidak Dirancang untuk Multiple Instance #

Skenario: Aplikasi yang acquire exclusive lock atau file

  v1 dan v2 berjalan bersamaan:
    v1 masih punya lock pada resource X
    v2 tidak bisa acquire lock → error
    → Conflict, data corruption possible

  Recreate memastikan v1 fully terminated sebelum v2 dimulai

Kasus 4: Development dan Non-Critical Environment #

Untuk environment development atau staging:
  → Downtime tidak menjadi masalah
  → Simplicity lebih penting dari availability
  → Recreate mempersingkat waktu deployment
  → Tidak perlu memikirkan kompatibilitas antar versi

Meminimalkan Downtime Window #

Meskipun ada downtime, prosesnya bisa dioptimalkan:

1. Optimasi terminationGracePeriodSeconds
   → Jangan terlalu besar; sesuaikan dengan waktu yang dibutuhkan
     aplikasi untuk selesaikan request yang sedang diproses
   → Terlalu kecil: request dipotong paksa
   → Terlalu besar: downtime window lebih panjang

2. Siapkan Pod baru dengan image yang sudah di-pull
   → Gunakan DaemonSet atau pre-pull image di node
   → Atau jalankan dummy Pod v2 sebelumnya untuk pre-pull
   kubectl run prefetch --image=my-api:v2 --dry-run=client
   # Image sudah di cache di node setelah Pod v2 pertama jalan

3. Optimasi startup time aplikasi
   → Database connection pooling yang cepat
   → Lazy loading untuk komponen yang tidak kritikal
   → Readiness probe yang cepat terpenuhi

4. Komunikasikan maintenance window
   → Gunakan status page untuk inform pengguna
   → Jadwalkan di jam traffic terendah
   → Siapkan maintenance page via Ingress

# Maintenance page via Ingress annotation saat Recreate
metadata:
  annotations:
    nginx.ingress.kubernetes.io/custom-http-errors: "503"
    nginx.ingress.kubernetes.io/default-backend: maintenance-service
# Saat tidak ada Pod yang ready, traffic akan diarahkan ke maintenance-service

Monitoring Selama Recreate #

# Pantau proses Recreate
kubectl rollout status deployment/api -n production
# Waiting for deployment "api" rollout to finish: 0 of 4 updated replicas are available...
# Waiting for deployment "api" rollout to finish: 1 of 4 updated replicas are available...
# deployment "api" successfully rolled out

# Hitung durasi downtime aktual
kubectl get events -n production | grep api
# Lihat timestamp antara Pod v1 terminated dan Pod v2 running

# Rollback jika v2 bermasalah
kubectl rollout undo deployment/api -n production

Ringkasan #

Recreate cocok untuk perubahan yang tidak backward-compatible — ketika v1 dan v2 tidak bisa berjalan bersamaan karena schema database, format data, atau exclusive resource.
Downtime ada, tapi bisa diminimalkan — optimasi graceful shutdown, pre-pull image, dan startup aplikasi yang cepat bisa memperpendek window.
Pilihan yang tepat untuk development environment — simplicity lebih penting dari availability di non-production; Recreate mempercepat deployment tanpa kompleksitas rolling update.
Pertimbangkan Blue/Green sebagai alternatif zero-downtime — jika resource tersedia dan rollback instan dibutuhkan, Blue/Green bisa memberikan switch yang atomik tanpa downtime.
Maintenance page selama downtime — konfigurasi Ingress default backend ke halaman maintenance agar pengguna mendapat pesan yang jelas, bukan error 503 yang membingungkan.
Komunikasikan jadwal — untuk production, jadwalkan di jam traffic terendah dan informasikan ke pengguna via status page sebelumnya.

← Sebelumnya: Canary Deployment Berikutnya: Database Migration Strategy →