Recreate #

Dalam dunia rekayasa perangkat lunak cloud-native, konsep downtime (waktu henti layanan) adalah sesuatu yang sebisa mungkin dihindari. Kita berlomba-lomba mengonfigurasi strategi Rolling Update, Blue/Green, atau Canary untuk menjamin ketersediaan layanan 100% (SLA tinggi) selama peluncuran versi baru. Namun, ada kalanya memaksakan rilis tanpa downtime (zero-downtime) justru menjadi keputusan arsitektural yang paling berbahaya. Kondisi ini biasanya terjadi ketika sistem mengalami perubahan fundamental yang tidak kompatibel ke belakang (breaking changes), baik pada tingkat database, format pesan, maupun mekanisme penguncian resource eksklusif.

Strategi Recreate adalah pendekatan rilis di mana Kubernetes menghentikan (scale down ke nol) seluruh replika Pod versi lama (v1) secara bersamaan, menunggu hingga seluruh proses pembersihan selesai, dan baru kemudian menjalankan ReplicaSet versi baru (v2) secara penuh. Meskipun strategi ini secara inheren melahirkan celah waktu henti (downtime window), ada skenario-skenario produksi spesifik di mana strategi Recreate bukan hanya dapat diterima, melainkan merupakan satu-satunya pilihan yang menjamin integritas data dan kestabilan cluster.

Mekanisme Arsitektural Strategi Recreate #

Ketika kita memperbarui manifes Deployment yang menggunakan strategi Recreate, siklus hidup transisi Pod dikelola secara ketat oleh Deployment Controller melalui langkah-langkah terstruktur berikut:

[ REVISI V1 ] ──────────────► [ TERMINASI V1 ] ──────────────► [ DOWNTIME WINDOW ] ──────────────► [ STARTUP V2 ] ──────────────► [ REVISI V2 ]
Pod 1: Running (v1)            Pod 1: Terminating (v1)         (Tidak ada Pod Running)             Pod 1: Pending/Init (v2)       Pod 1: Running (v2)
Pod 2: Running (v1)            Pod 2: Terminating (v1)                                             Pod 2: Pending/Init (v2)       Pod 2: Running (v2)
  1. Terminasi Massal v1: Deployment Controller mengubah skala (scale down) ReplicaSet v1 ke angka nol. Seluruh Pod v1 secara simultan masuk ke status Terminating.
  2. Graceful Shutdown: Pod v1 diberikan waktu toleransi (sesuai properti terminationGracePeriodSeconds) untuk menyelesaikan request HTTP aktif, mengosongkan antrean memori, dan melepas koneksi ke database.
  3. Pelepasan Resource Eksklusif: Setelah Pod v1 benar-benar terhapus dari sistem, Kubernetes melepas seluruh rujukan resource yang dikunci oleh Pod v1, seperti Persistent Volume (PV) atau binding port statis.
  4. Window Downtime: Pada fase ini, tidak ada satu pun Pod yang beroperasi untuk melayani trafik pengguna. Endpoint Service produksi akan kosong, dan trafik yang masuk akan menghasilkan respon HTTP 503 Service Unavailable.
  5. Inisialisasi v2: Deployment Controller mendeteksi bahwa seluruh Pod v1 telah bersih dari cluster, lalu mulai menginstruksikan ReplicaSet v2 untuk membuat dan menjalankan seluruh Pod v2 secara paralel.
  6. Startup & Probe: Pod v2 melewati proses bootstrap aplikasi, menjalankan readinessProbe, dan setelah dikonfirmasi sehat, Service mulai mengalirkan trafik kembali ke versi baru.

Skenario Kasus Penggunaan Mutlak Recreate Strategy #

Memahami kapan kita harus mengaktifkan strategi Recreate adalah kunci untuk menjaga integritas data. Berikut adalah empat use case utama di mana Recreate adalah pilihan terbaik:

1. Perubahan Skema Database Radikal (Breaking Schema Migrations) #

Jika kita menerapkan migrasi skema database yang memotong kompatibilitas mundur (non-backward compatible), menjalankan strategi zero-downtime (seperti Rolling Update) sangat berbahaya.

Misalkan kita melakukan perubahan nama kolom tabel database dari user_name menjadi username:

  • Jika Menggunakan Rolling Update: Pod v1 (lama) dan Pod v2 (baru) akan berjalan berdampingan selama beberapa menit. Begitu migrasi skema database dieksekusi di awal rilis, kolom user_name akan diubah menjadi username. Akibatnya, seluruh Pod v1 yang masih aktif melayani pengguna akan langsung crash seketika karena kueri database mereka (SELECT user_name FROM users) gagal menemukan kolom tersebut.
  • Jika Menggunakan Recreate: Kita menjamin bahwa seluruh Pod v1 yang membutuhkan kolom lama telah mati sepenuhnya sebelum skrip migrasi database dieksekusi dan Pod v2 dijalankan.

2. Inkonsistensi Serialisasi Data (Message Queue Serialization Shift) #

Kondisi ini terjadi ketika format pertukaran data antar-layanan berubah secara fundamental, misalnya migrasi dari format JSON menjadi Google Protocol Buffers (Protobuf) pada antrean pesan (Message Queue).

  • Jika Menggunakan Rolling Update: Produsen v2 mulai mempublikasikan pesan berformat Protobuf ke dalam broker pesan (seperti RabbitMQ atau Kafka). Konsumen v1 yang masih berjalan akan menarik pesan tersebut dan mengalami kegagalan fatal (crash loop) karena tidak dapat memparsing format Protobuf.
  • Jika Menggunakan Recreate: Kita mematikan seluruh produsen dan konsumen v1 secara bersamaan, mengosongkan antrean pesan (drain queue), dan baru kemudian menyalakan produsen dan konsumen v2 secara serempak.

3. Singleton Workload & Exclusive Resource Locking #

Beberapa aplikasi dirancang sebagai Singleton (hanya boleh ada tepat satu instance yang berjalan di seluruh cluster).

  • Contoh: Scheduler internal yang menarik data dari API pihak ketiga secara berkala, atau aplikasi stateful yang menempelkan disk penyimpanan (Persistent Volume) berbasis cloud dengan mode akses ReadWriteOnce (RWO).
  • Konsekuensi Rolling Update: Jika kita mencoba menjalankan instance kedua untuk menggantikan instance pertama, host cloud provider akan menolak penempelan volume disk karena volume tersebut masih terikat secara eksklusif ke host node instance pertama. Ini memicu deadlock Multi-Attach error. Strategi Recreate melepaskan kunci volume secara bersih terlebih dahulu sebelum menempelkannya ke kontainer baru.
sequenceDiagram
    participant DC as Deployment Controller
    participant Node1 as Worker Node 1
    participant Disk as Persistent Volume (RWO)
    participant Node2 as Worker Node 2
    
    DC->>Node1: Hapus Pod v1 (Scale Down to 0)
    Node1->>Disk: Lepas kunci Volume (Detach Disk)
    Disk-->>DC: Volume Berhasil Dilepas (Available)
    Note over DC: Selesai Fase Downtime
    DC->>Node2: Buat Pod v2 (Scale Up to 1)
    Node2->>Disk: Kunci Volume ke Node Baru (Attach Disk)
    Note over Node2: Pod v2 Ready melayani kueri

Taktik Meminimalkan Downtime Window #

Meskipun kita menerima fakta bahwa Recreate melahirkan downtime, kita memiliki tanggung jawab operasional untuk memperpendek durasi downtime tersebut seminimal mungkin (sering kali ditargetkan di bawah 30 detik). Berikut adalah taktik optimasi yang dapat kita terapkan:

1. Pemanasan Cache Image (Pre-pull Image / Image Prefetching) #

Sebagian besar durasi downtime pada strategi Recreate habis digunakan oleh node worker untuk mengunduh (download) image kontainer baru dari registry eksternal ke penyimpanan lokal node. Jika ukuran image mencapai gigabyte, downtime bisa memakan waktu menit.

Solusi #

Sebelum memicu update Deployment, jalankan sebuah Job Kubernetes sementara atau DaemonSet siaga yang memiliki tugas tunggal untuk mengunduh image baru ke seluruh node worker di cluster. Ketika proses Recreate dieksekusi, node worker langsung menjalankan kontainer baru dari cache lokal secara instan.

# ✓ SOLUSI: DaemonSet Prefetch untuk mengunduh image ke seluruh node sebelum rilis
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: image-prefetcher
  namespace: tools
spec:
  selector:
    matchLabels:
      name: prefetcher
  template:
    metadata:
      labels:
        name: prefetcher
    spec:
      # Kontainer ini langsung mati setelah image terunduh ke host node
      initContainers:
      - name: puller
        image: company/my-large-app:v2.0.0-new # Image baru yang akan dideploy
        command: ["echo", "Image pulled successfully"]
      containers:
      - name: sleep
        image: alpine:3.18
        command: ["sleep", "10"]

2. Optimasi terminationGracePeriodSeconds #

Secara default, Kubernetes menunggu hingga 30 detik untuk memberikan waktu shutdown sebelum mematikan kontainer secara paksa. Jika aplikasi kita sebenarnya dapat menutup seluruh koneksinya secara bersih dalam waktu 5 detik, mempertahankan nilai default 30 detik akan memperpanjang masa downtime secara sia-sia.

Solusi #

Ukur waktu shutdown aplikasi kita di lingkungan staging, lalu sesuaikan nilai terminationGracePeriodSeconds secara presisi.

spec:
  # Kurangi masa tunggu shutdown jika aplikasi dapat mati dengan cepat secara aman
  terminationGracePeriodSeconds: 10

3. Mengalihkan Trafik ke Halaman Pemeliharaan (Maintenance Page Redirection) #

Selama downtime berlangsung, pengguna tidak boleh melihat halaman error mentah browser (seperti HTTP 503 atau Connection Refused). Kita harus mengalihkan trafik ke halaman pemeliharaan (maintenance page) yang ramah pengguna secara dinamis.

Solusi #

Gunakan fitur Ingress Controller annotations untuk mendeteksi ketiadaan Pod yang sehat (empty endpoints) dan mengalihkan trafik secara otomatis ke backend statis cadangan.

# ✓ SOLUSI: Konfigurasi Ingress dengan Custom Error Page selama Downtime Recreate
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  namespace: production
  annotations:
    nginx.ingress.kubernetes.io/custom-http-errors: "502,503"
    # Mengarahkan error HTTP 502/503 ke service halaman pemeliharaan statis
    nginx.ingress.kubernetes.io/default-backend: maintenance-page-service
spec:
  ingressClassName: nginx
  rules:
  - host: app.company.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: app-core-service # Service aplikasi utama yang sedang di-Recreate
            port:
              number: 80

Anti-Pattern vs Solusi Terbaik #

Mari kita pelajari beberapa kesalahan kritis saat mengoperasikan strategi Recreate beserta perbaikan terbaiknya.

Anti-Pattern 1: Mengabaikan Pre-pull Image pada Rilis Recreate Produksi #

Melakukan update Deployment dengan strategi Recreate tanpa memastikan image baru telah tersedia di cache node worker. Kubelet akan menghapus seluruh Pod lama terlebih dahulu, lalu mulai men-download image baru. Jika koneksi internet cluster sedang mengalami gangguan atau ukuran image sangat besar, downtime cluster akan molor hingga puluhan menit.

Solusi Terbaik #

Gunakan taktik pre-pulling (DaemonSet prefetcher) atau pastikan pipeline CI/CD kita menjalankan verifikasi kesiapan cache image pada node sebelum memicu perubahan tag image pada Deployment.

Anti-Pattern 2: Menetapkan Grace Period Terlalu Singkat untuk Transaksi Finansial #

Mempersingkat parameter terminationGracePeriodSeconds menjadi sangat kecil (misalnya 2 detik) pada microservice pemroses pembayaran keuangan untuk meminimalkan downtime. Ketika proses Recreate dimulai, transaksi pembayaran yang sedang berjalan di tengah jalan akan dipotong secara paksa oleh signal SIGKILL. Hal ini memicu inkonsistensi data transaksi (data corruption) yang memerlukan rekonsiliasi manual yang rumit.

Solusi Terbaik #

Jangan korbankan keselamatan transaksi demi downtime. Jika transaksi membutuhkan waktu maksimal 20 detik untuk selesai, atur grace period minimal 25 detik, dan jalankan deployment di jam lalu lintas terendah (off-peak hours).

Manifes Lengkap Deployment Recreate Produksi #

Berikut adalah contoh manifes Deployment siap produksi yang menggunakan strategi Recreate secara aman, lengkap dengan batas resource, probe kesehatan, dan penanganan shutdown teratur:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: legacy-billing-engine
  namespace: finance
  labels:
    app: billing-engine
spec:
  # Aplikasi ini adalah singleton (hanya boleh berjalan 1 replika)
  replicas: 1
  # Mengaktifkan strategi Recreate untuk melepas volume eksklusif secara bersih
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: billing-engine
  template:
    metadata:
      labels:
        app: billing-engine
    spec:
      # Mengoptimalkan masa tunggu shutdown sesuai karakteristik database cleanup aplikasi
      terminationGracePeriodSeconds: 15
      containers:
      - name: engine
        image: company/billing-engine:v2.5.0
        resources:
          requests:
            cpu: "500m"
            memory: "512Mi"
          limits:
            cpu: "1000m"
            memory: "1Gi"
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /healthz/ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 3
          failureThreshold: 2
        livenessProbe:
          httpGet:
            path: /healthz/live
            port: 8080
          periodSeconds: 10
        volumeMounts:
        - name: transaction-logs
          mountPath: /var/log/billing
      volumes:
      - name: transaction-logs
        persistentVolumeClaim:
          claimName: billing-log-pvc # PVC dengan mode akses ReadWriteOnce

Checklist Audit Rilis Recreate #

Sebelum memicu deployment menggunakan strategi Recreate, pastikan tim engineering kita melakukan audit menggunakan checklist kesiapan berikut:

ANALISIS KEBUTUHAN DOWNTIME:
  □ Penggunaan strategi Recreate telah disetujui oleh tim bisnis dan operasional.
  □ Rilis telah dijadwalkan pada jam lalu lintas trafik terendah (off-peak hours).
  □ Halaman pengumuman pemeliharaan (maintenance page) telah disiapkan di tingkat Ingress.

OPTIMASI KECEPATAN & STRATEGI IMAGE:
  □ Image kontainer baru telah di-cache ke seluruh node worker melalui DaemonSet prefetcher.
  □ Parameter 'terminationGracePeriodSeconds' telah diatur seimbang (tidak terlalu lama, tidak memotong transaksi).
  □ Waktu inisialisasi awal aplikasi (startup bootstrap) telah dioptimalkan agar berjalan secepat mungkin.

VERIFIKASI RESOURCE & VOLUME LOCKING:
  □ Seluruh volume disk RWO dipastikan dapat dilepas (detached) secara otomatis dari host node lama.
  □ Koneksi database lama telah diputus secara graceful sebelum skrip migrasi database baru dieksekusi.
  □ Prosedur rollback cepat (rollout undo) telah disiapkan jika versi baru mengalami kegagalan fungsi.

Ringkasan #

  • Pilih Recreate untuk database non-backward compatible — Jika versi lama aplikasi akan langsung crash akibat perubahan skema database, gunakan Recreate untuk mematikan v1 sebelum v2 dijalankan.
  • Solusi utama Multi-Attach deadlock — Strategi Recreate melepaskan Persistent Volume (PV) berakses eksklusif secara bersih terlebih dahulu sebelum menempelkannya kembali ke Pod baru.
  • Lakukan pre-pull image untuk meminimalkan downtime — Gunakan DaemonSet prefetcher untuk mengunduh image ke node worker sebelum transisi dimulai guna mempersingkat masa waktu henti layanan.
  • Konfigurasikan halaman pemeliharaan otomatis — Manfaatkan fitur default-backend Ingress Controller untuk mengalihkan trafik ke halaman pemeliharaan statis yang ramah pengguna selama masa downtime.
  • Optimalkan grace period — Ukur waktu pembersihan (cleanup) aplikasi kita dan sesuaikan parameter terminationGracePeriodSeconds secara presisi agar tidak memperpanjang downtime.
  • Gunakan untuk singleton workload — Strategi Recreate menjamin tidak akan pernah ada dua instance aplikasi yang berjalan bersamaan di dalam cluster pada waktu yang sama.

← Sebelumnya: Canary Deployment   Berikutnya: Database Migration Strategy →

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