Strategi Deployment Kubernetes yang Perlu Anda Ketahui

Strategi deployment Kubernetes menentukan bagaimana aplikasi Anda bertransisi dari satu versi ke versi berikutnya tanpa mengganggu pengguna. Memilih strategi yang salah bisa berarti menit-menit downtime, rollout buruk yang menjangkau semua pengguna sekaligus, atau pemborosan biaya infrastruktur. Dalam artikel ini kita mengurai Rolling Update, Blue-Green, dan Canary deployment — kapan menggunakan masing-masing, trade-off-nya, dan contoh YAML yang langsung dapat diterapkan ke cluster Anda hari ini.

Mengapa Strategi Deployment Itu Penting

Setiap deployment membawa risiko. Image baru mungkin memperkenalkan regresi, migrasi database bisa merusak kompatibilitas mundur, atau masalah performa mungkin hanya muncul di bawah beban produksi. Strategi deployment adalah alat utama Anda untuk mengendalikan blast radius: berapa banyak pengguna yang terdampak, berapa lama, dan seberapa cepat Anda bisa pulih.

Default: Rolling Update

Kubernetes secara default mengganti Pod secara bertahap — memunculkan replika baru sebelum menghentikan yang lama. Dengan pengaturan maxSurge dan maxUnavailable Anda mengontrol seberapa agresif rollout berjalan. Rolling update bersifat zero-downtime untuk layanan stateless dan tidak memerlukan infrastruktur tambahan, menjadikannya pilihan tepat untuk sebagian besar deployment.

Kapan Rolling Update Tidak Cukup

Rolling update mencampur Pod lama dan baru selama jendela transisi, yang merusak skenario yang memerlukan isolasi versi ketat — misalnya migrasi skema database yang tidak kompatibel mundur dengan versi aplikasi lama. Dalam kasus tersebut Anda memerlukan Blue-Green atau Canary yang dikontrol feature flag.

Deployment Blue-Green di Kubernetes

Blue-Green mempertahankan dua environment identik — Blue (live) dan Green (staging). Anda men-deploy versi baru ke Green, menjalankan smoke test, kemudian membalik selector Service tunggal untuk merutekan 100% traffic dari Blue ke Green. Environment Blue lama tetap utuh untuk rollback instan: cukup balik selectornya.

Implementasi Blue-Green dengan Service Selector

Kuncinya adalah field selector pada Service. Deployment Blue maupun Green berbagi label 'app: myapp' yang sama tetapi berbeda dengan 'version: blue' dan 'version: green'. Mengubah Service selector adalah satu perintah kubectl patch dan berlaku dalam hitungan detik tanpa restart Pod apa pun.

# Blue deployment (current live)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-blue
  labels:
    app: myapp
    version: blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: blue
  template:
    metadata:
      labels:
        app: myapp
        version: blue
    spec:
      containers:
      - name: myapp
        image: myapp:v1.0.0
        ports:
        - containerPort: 8080
---
# Service - switch traffic by changing selector
apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  selector:
    app: myapp
    version: blue   # change to "green" to cut over
  ports:
  - port: 80
    targetPort: 8080

Implikasi Biaya dan Sumber Daya

Blue-Green menggandakan jejak komputasi selama transisi. Untuk deployment besar ini cukup signifikan. Mitigasinya adalah men-scale Green turun ke nol setelah cutover dikonfirmasi stabil, kemudian men-scale Blue turun. Tools seperti Argo Rollouts mengotomasi siklus hidup ini dan bahkan mengintegrasikan dengan load balancer untuk weighted traffic splitting tanpa menduplikasi Service.

Canary Deployment: Pergeseran Traffic Bertahap

Canary release mengirimkan sebagian kecil traffic produksi nyata ke versi baru sementara mayoritas terus menghantam versi stabil. Anda mengamati error rate, latensi, dan metrik bisnis kustom sebelum secara bertahap meningkatkan bobot canary. Jika ada yang terlihat salah Anda langsung mengalihkan 100% kembali ke stabil.

Canary Native Kubernetes dengan Rasio Replika

Canary native paling sederhana menggunakan dua Deployment (stable: 9 replika, canary: 1 replika) yang sama-sama dipilih oleh Service yang sama. Dengan total 10 Pod, sekitar 10% permintaan mendarat di canary. Untuk kontrol lebih halus tanpa perubahan Ingress Anda memerlukan service mesh (Istio, Linkerd) atau Ingress controller yang mendukung traffic splitting.

Argo Rollouts: Progressive Delivery Tingkat Lanjut

Argo Rollouts memperluas Kubernetes dengan custom resource Rollout yang mengimplementasikan Blue-Green dan Canary secara native, mengintegrasikan dengan analysis template (kueri metrik otomatis untuk mempromosikan atau membatalkan), dan menyediakan dashboard UI. Ini adalah pilihan siap produksi ketika Anda memerlukan analisis Canary otomatis tanpa memelihara skrip kustom.

Analysis Template dan Promosi Otomatis

AnalysisTemplate mendefinisikan kueri PromQL dan kriteria keberhasilan. Selama rollout Canary, Argo Rollouts menjalankan analisis pada setiap interval langkah. Jika kueri mengembalikan nilai di luar ambang batas — misalnya error rate di atas 1% — rollout secara otomatis dibatalkan dan versi stabil dipulihkan tanpa intervensi manusia apa pun.

Mengintegrasikan Rollouts dengan GitHub Actions

Setelah pipeline CI membangun dan mendorong image baru, langkah CD dapat memanggil 'kubectl argo rollouts set image' untuk memulai progressive delivery. Pipeline kemudian dapat menunggu dan memantau status rollout serta menggagalkan workflow jika rollout dibatalkan.

Memilih Strategi yang Tepat

Rolling Update adalah default dan mencakup 80% kasus penggunaan — layanan stateless, aplikasi frontend, dan sebagian besar backend API. Blue-Green ideal untuk migrasi database, environment sensitif compliance yang memerlukan cutover bersih, atau kapan pun Anda memerlukan rollback instan. Canary terbaik ketika Anda menginginkan sinyal pengguna nyata sebelum rollout penuh, terutama untuk layanan traffic tinggi di mana bahkan 1% error rate memiliki dampak bisnis yang terukur.

Matriks Keputusan

Tanyakan pada diri sendiri: apakah versi baru berbagi skema database dengan yang lama? Jika ya dan migrasinya tidak kompatibel mundur, Anda butuh Blue-Green. Apakah Anda memiliki stack metrik yang kuat dan ingin paparan pengguna bertahap? Gunakan Canary dengan Argo Rollouts. Apakah perubahan berisiko rendah dan sepenuhnya kompatibel mundur? Rolling Update dengan nilai maxUnavailable yang wajar sudah cukup.

Konsep kunci deployment Kubernetes yang perlu dipahami: Deployment, Service, HPA (Horizontal Pod Autoscaler), canary release, and rolling update.

Artikel Terkait

• CI/CD dengan GitHub Actions: Dari Nol Hingga Produksi
• GitOps dengan ArgoCD dan Flux