Rolling Update #

Rolling Update adalah strategi deployment default di Kubernetes — mengganti Pod versi lama dengan versi baru secara bertahap, tidak sekaligus. Hasilnya adalah deployment yang tidak menyebabkan downtime, karena selalu ada cukup Pod yang berjalan selama proses berlangsung. Memahami parameter yang mengontrol kecepatan dan keamanan proses ini penting untuk merancang deployment yang benar-benar zero-downtime.

Cara Kerja Rolling Update #

Saat kamu memperbarui image di sebuah Deployment, Kubernetes tidak langsung menghapus semua Pod lama. Controller membuat ReplicaSet baru untuk versi baru, lalu secara bertahap menambah Pod baru sambil mengurangi Pod lama.

Deployment: api, replicas: 4, maxSurge: 1, maxUnavailable: 0

Kondisi awal:
  ReplicaSet v1: [v1] [v1] [v1] [v1]   ← 4 Pod running

kubectl set image deployment/api api=my-api:v2

Langkah 1: Buat Pod v2 pertama (total: 5 Pod, sesuai maxSurge=1)
  ReplicaSet v1: [v1] [v1] [v1] [v1]
  ReplicaSet v2: [v2]                   ← menunggu Ready

Langkah 2: Pod v2 Ready → hapus Pod v1 (total: 4, tidak turun di bawah maxUnavailable=0)
  ReplicaSet v1: [v1] [v1] [v1]
  ReplicaSet v2: [v2]

Langkah 3: Buat Pod v2 berikutnya
  ReplicaSet v1: [v1] [v1] [v1]
  ReplicaSet v2: [v2] [v2]

...berulang sampai semua Pod v2 Running dan v1 dihapus:

Kondisi akhir:
  ReplicaSet v1: (0 Pod, masih ada untuk rollback)
  ReplicaSet v2: [v2] [v2] [v2] [v2]

Parameter Kunci: maxSurge dan maxUnavailable #

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1           # berapa banyak Pod EKSTRA boleh ada di atas replicas
      maxUnavailable: 0     # berapa banyak Pod boleh tidak available selama update

maxSurge — berapa Pod tambahan yang boleh dibuat di atas jumlah replicas selama update. Bisa angka absolut atau persentase.

maxUnavailable — berapa Pod yang boleh tidak tersedia (tidak Running atau tidak Ready) selama update. Bisa angka absolut atau persentase.

Kombinasi yang umum digunakan:

Zero-downtime ketat (default aman):
  maxSurge: 1, maxUnavailable: 0
  → Selalu ada replicas yang penuh tersedia
  → Update lebih lambat karena harus tunggu Pod baru Ready sebelum hapus yang lama

Update cepat (resource lebih):
  maxSurge: 25%, maxUnavailable: 0
  → Bisa buat banyak Pod baru sekaligus
  → Butuh resource ekstra selama proses

Hemat resource:
  maxSurge: 0, maxUnavailable: 1
  → Hapus Pod lama dulu, baru buat yang baru
  → Ada sesaat kapasitas berkurang 1 Pod

Keseimbangan kecepatan-keamanan:
  maxSurge: 1, maxUnavailable: 1
  → Default Kubernetes jika tidak dikonfigurasi
  → Update cukup cepat dengan risiko downtime minimal

Konfigurasi Lengkap #

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
  namespace: production
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  minReadySeconds: 10          # tunggu 10 detik setelah Pod Ready sebelum lanjut
  progressDeadlineSeconds: 300 # timeout keseluruhan update (default: 600s)
  revisionHistoryLimit: 5      # simpan 5 ReplicaSet lama untuk rollback
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
      - name: api
        image: my-api:v2
        readinessProbe:         # WAJIB untuk rolling update yang aman
          httpGet:
            path: /health/ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5
          failureThreshold: 3
        lifecycle:
          preStop:              # graceful shutdown — selesaikan request yang sedang berjalan
            exec:
              command: ["/bin/sh", "-c", "sleep 5"]
      terminationGracePeriodSeconds: 30

Peran Readiness Probe dalam Rolling Update #

Readiness probe adalah komponen yang paling kritis untuk rolling update yang benar-benar zero-downtime. Tanpanya, Kubernetes akan menandai Pod sebagai “Ready” segera setelah container berjalan — padahal mungkin aplikasi di dalamnya belum siap menerima traffic.

Tanpa readiness probe:

  Pod v2 dibuat → container started → langsung ditandai Ready
  → Traffic dikirim ke Pod v2 yang belum selesai inisialisasi
  → 503 errors, connection refused selama beberapa detik

  Kubernetes mulai hapus Pod v1 sebelum v2 benar-benar siap
  → Gap di mana tidak ada Pod yang cukup untuk melayani traffic

Dengan readiness probe:

  Pod v2 dibuat → container started
  → Kubernetes probe /health/ready setiap 5 detik
  → Sampai probe berhasil, Pod tidak masuk ke Endpoints Service
  → Tidak ada traffic ke Pod v2 sampai benar-benar siap
  → Kubernetes baru hapus Pod v1 setelah v2 dikonfirmasi Ready

Perintah Monitoring dan Kontrol #

# Pantau progress rolling update secara real-time
kubectl rollout status deployment/api -n production

# Output selama update:
# Waiting for deployment "api" rollout to finish: 1 out of 4 new replicas have been updated...
# Waiting for deployment "api" rollout to finish: 2 out of 4 new replicas have been updated...
# deployment "api" successfully rolled out

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

# Output:
# REVISION  CHANGE-CAUSE
# 1         kubectl apply --filename=api-v1.yaml
# 2         kubectl apply --filename=api-v2.yaml (image: my-api:v2)

# Simpan catatan change cause
kubectl annotate deployment/api \
  kubernetes.io/change-cause="upgrade to v2 with new auth module" \
  -n production

Rollback #

# Rollback ke versi sebelumnya (revision terakhir)
kubectl rollout undo deployment/api -n production

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

# Pause rolling update (untuk investigasi)
kubectl rollout pause deployment/api -n production

# Resume setelah investigasi
kubectl rollout resume deployment/api -n production

Diagnosis Masalah Rolling Update #

# Update stuck atau lambat?
kubectl describe deployment api -n production
# Perhatikan bagian Conditions dan Events

# Lihat ReplicaSet yang terlibat
kubectl get replicaset -n production
# NAME          DESIRED   CURRENT   READY   AGE
# api-v2-abc    4         4         2       3m    ← masih ada 2 yang belum ready
# api-v1-def    2         2         2       1d

# Pod mana yang tidak ready?
kubectl get pods -n production -l app=api
# Lihat kolom READY (harus 1/1) dan STATUS

# Log Pod yang bermasalah
kubectl logs <pod-name> -n production

# Describe Pod untuk lihat events dan readiness probe status
kubectl describe pod <pod-name> -n production

Masalah umum yang menyebabkan rolling update stuck:

Pod baru tidak bisa start:
  → Image tidak bisa di-pull (ImagePullBackOff)
  → OOMKilled karena resource limit terlalu kecil
  → ConfigMap atau Secret yang direferensikan tidak ada

Pod baru tidak pernah Ready:
  → Readiness probe gagal terus (aplikasi error saat startup)
  → Dependency belum tersedia (database, service lain)
  → Port yang di-probe salah atau path tidak ada

progressDeadlineSeconds terlewati:
  → Kubernetes menandai Deployment sebagai Failed
  → Update berhenti tapi Pod lama masih berjalan
  → Perlu investigasi dan fix sebelum retry

Ringkasan #

• maxSurge dan maxUnavailable mengontrol kecepatan dan keamanan — maxSurge: 1, maxUnavailable: 0 adalah konfigurasi zero-downtime yang paling aman; lebih lambat tapi tidak ada Pod yang tidak available.
• Readiness probe adalah syarat mutlak — tanpa readiness probe, Pod dianggap Ready sebelum aplikasi siap; traffic masuk sebelum waktunya dan menyebabkan error.
• minReadySeconds untuk stabilisasi — tunggu N detik setelah Pod Ready sebelum lanjut update; memberikan buffer jika masalah baru muncul setelah startup.
• Rollback cepat dengan kubectl rollout undo — Kubernetes menyimpan ReplicaSet lama sesuai revisionHistoryLimit; rollback hanya butuh beberapa menit.
• Pause untuk investigasi selama update berlangsung — jika ada masalah di tengah update, pause dulu sebelum memutuskan rollback atau fix-forward.
• progressDeadlineSeconds sebagai safety net — jika update tidak selesai dalam batas waktu, Kubernetes tandai sebagai Failed; tidak ada silent stuck deployment.

← Sebelumnya: Deployment Strategy Overview   Berikutnya: Blue/Green Deployment →