Deployment #

Deployment adalah resource yang paling sering kamu gunakan di Kubernetes untuk menjalankan aplikasi stateless. Ia menyediakan semua yang dibutuhkan untuk lifecycle management aplikasi: deklarasi jumlah replica, strategi update tanpa downtime, history versi untuk rollback, dan self-healing saat Pod mati. Memahami Deployment secara menyeluruh berarti memahami cara menjalankan aplikasi web, API, dan service apapun yang bisa di-scale horizontal di Kubernetes.

Struktur Manifest Deployment #

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-deployment
  namespace: production
  labels:
    app: api
spec:
  replicas: 3                      # jumlah Pod yang diinginkan
  revisionHistoryLimit: 10         # jumlah ReplicaSet lama yang disimpan

  selector:
    matchLabels:
      app: api                     # Deployment mengelola Pod berlabel ini

  strategy:
    type: RollingUpdate            # RollingUpdate | Recreate
    rollingUpdate:
      maxSurge: 1                  # Pod ekstra yang boleh dibuat selama update
      maxUnavailable: 0            # Pod yang boleh tidak tersedia selama update

  template:                        # template Pod yang akan dibuat
    metadata:
      labels:
        app: api                   # harus cocok dengan selector di atas
    spec:
      containers:
      - name: api
        image: my-registry/api:v2.1.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: "250m"
            memory: "128Mi"
          limits:
            cpu: "500m"
            memory: "256Mi"
        readinessProbe:
          httpGet:
            path: /health/ready
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 5

Strategi Update: RollingUpdate #

RollingUpdate adalah strategi default yang memungkinkan pembaruan tanpa downtime. Kubernetes mengganti Pod lama dengan yang baru secara bertahap.

RollingUpdate dengan maxSurge: 1, maxUnavailable: 0, replicas: 3:

Kondisi awal:
  [Pod v1] [Pod v1] [Pod v1]       3 Pod berjalan

Step 1 — buat Pod v2 (surge):
  [Pod v1] [Pod v1] [Pod v1]
  [Pod v2]                         4 Pod (maxSurge: +1 diizinkan)

Step 2 — Pod v2 ready, hapus Pod v1:
  [Pod v1] [Pod v1]
  [Pod v2]                         3 Pod (tidak ada yang unavailable)

Step 3 — buat Pod v2 kedua:
  [Pod v1] [Pod v1]
  [Pod v2] [Pod v2]

Step 4 — Pod v2 kedua ready, hapus Pod v1:
  [Pod v1]
  [Pod v2] [Pod v2]

Step 5 — buat Pod v2 ketiga:
  [Pod v1]
  [Pod v2] [Pod v2] [Pod v2]

Step 6 — Pod v2 ketiga ready, hapus Pod v1 terakhir:
  [Pod v2] [Pod v2] [Pod v2]       update selesai, tidak ada downtime

maxSurge — berapa Pod ekstra yang boleh dibuat di atas replicas selama update. Bisa berupa angka absolut (1) atau persentase (25%).

maxUnavailable — berapa Pod yang boleh tidak tersedia (tidak siap menerima traffic) selama update. Nilai 0 berarti tidak ada downtime sama sekali — selalu ada Pod yang siap.

Konfigurasi yang umum digunakan:

Untuk zero-downtime (default yang aman):
  maxSurge: 1
  maxUnavailable: 0

Untuk update cepat (butuh lebih banyak resource sementara):
  maxSurge: 50%
  maxUnavailable: 0

Untuk hemat resource (tapi ada brief downtime):
  maxSurge: 0
  maxUnavailable: 1

Strategi Update: Recreate #

Recreate menghapus semua Pod lama sebelum membuat Pod baru. Ini menyebabkan downtime, tapi berguna untuk kasus tertentu:

  strategy:
    type: Recreate
    # Tidak ada konfigurasi tambahan untuk Recreate

Recreate:

Kondisi awal:
  [Pod v1] [Pod v1] [Pod v1]

Step 1 — hapus semua Pod v1:
  (tidak ada Pod — DOWNTIME)

Step 2 — buat semua Pod v2:
  [Pod v2] [Pod v2] [Pod v2]

Gunakan Recreate jika:
  ✓ Aplikasi tidak bisa berjalan dalam dua versi secara bersamaan
    (misalnya schema database tidak backward-compatible)
  ✓ Resource cluster sangat terbatas, tidak bisa handle Pod ekstra
  ✓ Downtime singkat dapat ditoleransi

Gunakan RollingUpdate jika:
  ✓ Hampir semua kasus produksi lainnya

Melakukan Update #

# Update image dengan perintah langsung
kubectl set image deployment/api-deployment api=my-registry/api:v2.2.0

# Update via manifest (cara yang lebih direkomendasikan untuk production)
# 1. Edit deployment.yaml: ubah image tag
# 2. Apply:
kubectl apply -f deployment.yaml

# Pantau progress update
kubectl rollout status deployment/api-deployment
# Output: Waiting for deployment "api-deployment" rollout to finish:
#         1 out of 3 new replicas have been updated...
#         deployment "api-deployment" successfully rolled out

# Lihat history update
kubectl rollout history deployment/api-deployment
# Output:
# REVISION  CHANGE-CAUSE
# 1         <none>
# 2         <none>
# 3         <none>

# Tambahkan annotation untuk mencatat alasan update (berguna untuk history)
kubectl annotate deployment/api-deployment \
  kubernetes.io/change-cause="Update to v2.2.0: fix memory leak in handler"

Rollback #

Salah satu fitur paling berharga Deployment adalah kemampuan rollback ke versi sebelumnya:

# Rollback ke versi sebelumnya
kubectl rollout undo deployment/api-deployment

# Rollback ke revision tertentu
kubectl rollout history deployment/api-deployment   # lihat revision yang tersedia
kubectl rollout undo deployment/api-deployment --to-revision=2

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

Rollback bekerja dengan cara yang elegan: Deployment tidak “membalik” perubahan, melainkan scale up ReplicaSet lama dan scale down ReplicaSet yang aktif.

Rollback dari v2 ke v1:

Sebelum rollback:
  ReplicaSet v1: 0 replicas (disimpan, tidak dihapus)
  ReplicaSet v2: 3 replicas (aktif)

Proses rollback (sama seperti rolling update, tapi ke versi sebelumnya):
  ReplicaSet v1: scale up ke 3
  ReplicaSet v2: scale down ke 0

Setelah rollback:
  ReplicaSet v1: 3 replicas (aktif lagi)
  ReplicaSet v2: 0 replicas (disimpan)

Pause dan Resume Update #

Berguna untuk inspeksi di tengah proses update (canary manual sederhana):

# Mulai update
kubectl set image deployment/api-deployment api=my-registry/api:v2.2.0

# Pause setelah beberapa Pod terupdate (inspeksi manual)
kubectl rollout pause deployment/api-deployment

# Cek kondisi — beberapa Pod v2.2.0 sudah berjalan, sisanya masih v2.1.0
kubectl get pods

# Jika semuanya baik, lanjutkan update
kubectl rollout resume deployment/api-deployment

# Jika ada masalah, rollback
kubectl rollout undo deployment/api-deployment

Scaling #

# Scale secara imperatif
kubectl scale deployment/api-deployment --replicas=5

# Scale via manifest (untuk gitops workflow)
# Edit spec.replicas di deployment.yaml, lalu:
kubectl apply -f deployment.yaml

# Lihat status scaling
kubectl get deployment api-deployment
# NAME             READY   UP-TO-DATE   AVAILABLE   AGE
# api-deployment   5/5     5            5           2h

Deployment yang Tidak Kunjung Selesai #

Kadang rolling update berjalan tapi tidak selesai dalam waktu yang wajar — Pod baru stuck di Pending atau CrashLoopBackOff:

# Cek status — jika ini hang berarti ada masalah
kubectl rollout status deployment/api-deployment --timeout=5m

# Diagnosis:
kubectl get pods                          # cari Pod yang tidak Ready
kubectl describe pod <pod-name>           # lihat Events
kubectl logs <pod-name> --previous        # log dari container sebelum crash

# Jika sudah yakin ada masalah, rollback segera
kubectl rollout undo deployment/api-deployment

Deployment punya field spec.progressDeadlineSeconds (default: 600 detik). Jika update tidak selesai dalam waktu ini, Deployment ditandai sebagai False di condition Progressing — berguna untuk alerting.

Ringkasan #

  • Deployment untuk semua aplikasi stateless — bukan Pod langsung; Deployment menyediakan self-healing, rolling update, dan rollback.
  • RollingUpdate dengan maxUnavailable: 0 — konfigurasi standar untuk zero-downtime deployment; Pod lama tidak dihapus sebelum Pod baru siap.
  • Recreate hanya jika dua versi tidak bisa berjalan bersamaan — ada downtime singkat; gunakan hanya jika ada alasan teknis yang kuat.
  • kubectl rollout history dan undo — rollback ke revision manapun dalam history; Deployment menyimpan ReplicaSet lama untuk tujuan ini.
  • Update via manifest, bukan imperatif — kubectl apply -f lebih mudah di-audit dan di-version control dibanding kubectl set image.
  • revisionHistoryLimit untuk kontrol storage — default 10 ReplicaSet lama disimpan; turunkan di cluster dengan storage terbatas, tapi jangan sampai 0 jika butuh rollback.

← Sebelumnya: ReplicaSet   Berikutnya: StatefulSet →

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