KAL
Menu

Deployment

Deklarasi template Pod melalui Deployment beserta mekanisme rollout terkelola dari pihak controller.

Daftar isi

Deployment adalah objek Kubernetes yang mendeklarasikan template Pod beserta jumlah replikanya, lalu mengelola peralihan dari versi lama ke versi baru secara bertahap. Objek ini berada satu lapisan di atas ReplicaSet dan menjadi cara standar menjalankan aplikasi yang tidak berhenti. Topik ini membahas struktur manifest, rantai kepemilikan dari Pod ke ReplicaSet lalu ke Deployment, serta strategi RollingUpdate dengan parameter maxSurge dan maxUnavailable.

Deployment sebagai pengelola ReplicaSet#

Membuat Pod secara manual mengikat pengelolaan pada objek yang tidak punya mekanisme pemulihan. Apabila Pod dihapus, tidak ada yang membuat ulang, dan setiap perubahan harus dilakukan per Pod. ReplicaSet memperbaiki bagian replikasi, tetapi tidak menawarkan strategi peralihan versi. Deployment melengkapi lapisan terakhir, yaitu mengelola sekumpulan ReplicaSet beserta urutan pembuatannya.

Rantai kepemilikannya berurutan dan eksplisit dari Pod ke ReplicaSet lalu ke Deployment. Deployment memiliki ReplicaSet yang dibuatnya melalui bidang metadata.ownerReferences, dan setiap ReplicaSet memiliki sekumpulan Pod yang dihasilkannya. Apabila Deployment dihapus, penghapusan berjalan turun dari Deployment ke ReplicaSet lalu ke Pod secara otomatis. Urutan ini juga menjadi dasar pencatatan revisi, karena setiap versi template Pod diwakili oleh satu ReplicaSet tersendiri.

Manifest Deployment memuat seluruh lapisan tersebut dalam satu berkas. Bagian spec.template berisi definisi Pod yang diwariskan ke ReplicaSet, sedangkan bagian spec.strategy mengatur cara peralihannya:

yaml deployment.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: catatan
  labels:
    app: catatan
spec:
  replicas: 5
  selector:
    matchLabels:
      app: catatan
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  template:
    metadata:
      labels:
        app: catatan
    spec:
      containers:
        - name: catatan
          image: nginx:1.26
          ports:
            - containerPort: 80

Bidang spec.selector pada Deployment tidak boleh berubah setelah objek dibuat, karena selector menentukan ReplicaSet mana yang berada di bawah kendalinya. Template Pod justru boleh berubah, dan perubahan itulah yang memicu rollout baru. Nilai replicas: 5 pada manifest menjadi jumlah replika yang diwariskan ke ReplicaSet aktif.

Strategi RollingUpdate#

Strategi RollingUpdate menggantikan Pod lama dengan Pod baru secara bertahap, sehingga kapasitas layanan tidak pernah jatuh sampai nol. Dua parameter mengendalikan seberapa agresif peralihan tersebut. maxSurge menyatakan jumlah Pod tambahan yang boleh dibuat di atas jumlah replika normal, sedangkan maxUnavailable menyatakan jumlah Pod yang boleh tidak tersedia selama proses berjalan. Keduanya ditulis sebagai bilangan bulat atau persentase, dengan pembulatan ke atas untuk maxSurge dan ke bawah untuk maxUnavailable.

Pada Deployment dengan sepuluh replika, maxSurge: 25% berarti tiga Pod tambahan, sedangkan maxUnavailable: 25% berarti dua Pod boleh hilang. Nilai default keduanya adalah 25 persen. Strategi Recreate merupakan alternatif yang menghapus seluruh Pod lama sebelum Pod baru dibuat, sehingga terjadi jeda tanpa kapasitas dan hanya cocok untuk aplikasi yang menerima waktu henti.

Simulasi berikut menghitung perputaran langkah demi langkah untuk Deployment dengan lima replika, maxSurge 1, dan maxUnavailable 1. Pod baru perlu waktu untuk siap, sehingga pembuatan dan penghapusan bergantian satu per satu:

python 
import math

REPLIKA = 5      # spec.replicas yang diinginkan
MAX_SURGE = 1    # pod tambahan yang boleh dibuat di atas jumlah normal
MAX_UNAVAIL = 1  # pod yang boleh tidak tersedia selama perputaran

LAMA_MAKS = REPLIKA + MAX_SURGE   # batas total pod saat perputaran
SIAP_MIN = REPLIKA - MAX_UNAVAIL  # pod yang harus tetap tersedia

lama, baru, langkah = REPLIKA, 0, 0
print(f"{'langkah':>7}  {'aksi':<15} {'lama':>4} {'baru':>4} {'total':>5}")
print(f"{'awal':>7}  {'-':<15} {lama:>4} {baru:>4} {lama + baru:>5}")
while lama > 0:
    langkah += 1
    if lama + baru < LAMA_MAKS:
        # ruang surge tersedia, pod baru dibuat dan menunggu siap
        baru += 1
        aksi = "buat pod baru"
    else:
        # pod baru sudah siap, satu pod lama dihapus
        lama -= 1
        aksi = "hapus pod lama"
    print(f"{langkah:>7}  {aksi:<15} {lama:>4} {baru:>4} {lama + baru:>5}")

# konversi persentase: maxSurge dibulatkan ke atas, maxUnavailable ke bawah
for jumlah in (5, 10):
    surge = math.ceil(jumlah * 25 / 100)
    unavail = math.floor(jumlah * 25 / 100)
    print(f"{jumlah} replika dengan 25%: maxSurge {surge}, maxUnavailable {unavail}")
text Keluaran 
langkah  aksi            lama baru total
   awal  -                  5    0     5
      1  buat pod baru      5    1     6
      2  hapus pod lama     4    1     5
      3  buat pod baru      4    2     6
      4  hapus pod lama     3    2     5
      5  buat pod baru      3    3     6
      6  hapus pod lama     2    3     5
      7  buat pod baru      2    4     6
      8  hapus pod lama     1    4     5
      9  buat pod baru      1    5     6
     10  hapus pod lama     0    5     5
5 replika dengan 25%: maxSurge 2, maxUnavailable 1
10 replika dengan 25%: maxSurge 3, maxUnavailable 2

Tabel di atas memperlihatkan total Pod yang naik ke enam pada setiap langkah pembuatan, sesuai batas maxSurge, lalu turun ke lima setelah satu Pod lama berhenti. Ketersediaan tidak pernah jatuh di bawah empat Pod sesuai batas maxUnavailable. Baris terakhir menunjukkan aturan pembulatan persentase, yaitu ke atas untuk maxSurge dan ke bawah untuk maxUnavailable. Diagram berikut merangkum keadaan dalam tiga tahap, mulai dari Pod lama yang berjalan penuh, keadaan puncak saat Pod tambahan dibuat, sampai seluruh Pod beralih ke versi baru:

RollingUpdate dengan maxSurge 1 dan maxUnavailable 1total pod tidak pernah di bawah 4 dan tidak pernah di atas 6Tahap awalpod lama 5, pod baru 0Puncak perputaranpuncak total 6 podsatu pod lama dihapus per langkahSetelah selesaipod lama 0, pod baru 5pod lama (nginx:1.26)pod baru (nginx:1.27)pod lama yang dihapus berikutnya
Tiga keadaan selama rolling update dengan maxSurge 1 dan maxUnavailable 1

Pemilihan nilai kedua parameter bergantung pada sifat aplikasi. Deployment dengan satu replika biasanya menggunakan maxSurge 1 dan maxUnavailable 0, karena kehadiran Pod lama lebih penting daripada kecepatan peralihan, dan Pod baru dijamin siap lebih dahulu sebelum Pod lama berhenti. Kluster dengan banyak replika lebih cocok dengan persentase, karena perputaran tetap proporsional saat jumlah replika berubah.

Memantau rollout#

Perputaran yang sedang berjalan dapat dipantau tanpa membuka dasbor. Perintah kubectl rollout status menunggu sampai Deployment dinyatakan selesai sambil mencetak kemajuannya, sedangkan kubectl get deploy merangkum keadaan dalam kolom READY, UP-TO-DATE, dan AVAILABLE. Kolom UP-TO-DATE adalah jumlah replika yang telah menggunakan template terbaru, sehingga selisih antara READY dan UP-TO-DATE menandakan Pod baru yang masih dalam proses.

bash 
# tidak-dijalankan
# terapkan manifest Deployment ke kluster
kubectl apply -f deployment.yaml

# pantau perputaran sampai dinyatakan selesai
kubectl rollout status deployment catatan

# ringkas keadaan Deployment setelah rollout
kubectl get deploy
text Contoh keluaran 
deployment.apps/catatan created
Waiting for deployment "catatan" rollout to finish: 0 of 5 updated replicas are available...
deployment "catatan" successfully rolled out
NAME      READY   UP-TO-DATE   AVAILABLE   AGE
catatan   5/5     5            5           41s

Keluaran di atas memperlihatkan urutan yang perlu dipahami. Pesan Waiting muncul selama Pod baru dibuat dan menunggu keadaan siap, pesan successfully rolled out menandakan seluruh replika menggunakan template terbaru, dan tabel akhir menunjukkan lima Pod siap dari lima yang diinginkan. Apabila perputaran macet, kolom UP-TO-DATE yang tertinggal menjadi petunjuk pertama untuk menyelidiki keadaan Pod barunya.

Ringkasan#

  • Deployment mengelola sekumpulan ReplicaSet, sehingga rantai kepemilikan berbentuk Pod, ReplicaSet, lalu Deployment, dan penghapusan berjalan turun secara otomatis.
  • Perubahan template Pod membuat ReplicaSet baru, sedangkan ReplicaSet lama dipertahankan dengan jumlah nol sebagai revisi.
  • Strategi RollingUpdate mengganti Pod secara bertahap dengan batas maxSurge untuk kelebihan kapasitas dan maxUnavailable untuk Pod yang boleh tidak tersedia.
  • Persentase dibulatkan ke atas untuk maxSurge dan ke bawah untuk maxUnavailable.

Referensi#