Hal-hal yang perlu diperhatikan untuk menerapkan Zero Downtime pada k8s

Sep 20, 2022 min read

Zero Downtime Okee, untuk kali ini catatan yang akan ditulis adalah mengenai hal-hal apa yang perlu diperhatikan ketika menerapkan Zero Downtime pada kubernetes.

Pertama | ReplicaSets

Menentukan ReplicaSets pada jumlah batas minimum, yaitu 3. Kenapa demikian? Ini dikarenakan jika suatu saat ada pods kita yang crash kita masih memiliki pods yang lain yang masih berjalan.

Links terkait ReplicaSets

Kedua | podAntiAffinity

Bayangkan apabila anda memiliki 3 replicasets, akan tetapi semuanya berada pada 1 node dan node itu tidak bisa diakses. Maka semua service tidak bisa diakses juga, maka butuh yang namanya “podAntiAffinity” yang berguna untuk melakukan pemasangan pod sesuai dengan rule yang sudah kita tentukan.

Pada kasus ini jika kita memiliki 3 replicasets, maka hal yang terbaik yang bisa kita lakukan adalah memisah replica tersebut ke setiap node yang kita miliki, sehingga tidak menumpuk di 1 node saja. Apa bila sewaktu-waktu ada node yang tidak bisa diakses, masih ada replicasets kita yang berjalan pada node lain.

Links terkait podAntiAffinity

contoh yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis-cache
spec:
  selector:
    matchLabels:
      app: store
  replicas: 3
  template:
    metadata:
      labels:
        app: store
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - store
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: redis-server
        image: redis:3.2-alpine

Ketiga | Resource Declaration

Ini perlu untuk ditentukan untuk menanggulangi ketika node mengalami overused, dikarenakan dari deployment yang sudah terpasang menggunakan default resource, padahal untuk penggunaan tidak terlalu tinggi.

Maka perlu adanya deklarasi untuk minimum dan maksimum resources, agar setiap pod yang jalan menggunakan resource sesuai kebutuhan saja.

Link terkait Resource Declaration

Keempat | Readiness & Liveness Probe

Dalam menjalankan pod kita butuh untuk mengetahui pod tersebut sudah bisa diakses atau belum, lebih dari itu meskipun pod sudah bisa diakses namun pada kondisi tertentu pod gagal untuk memproses service padahal secara status masih running. Oleh karena itu kita membutuhkan yang namanya Readiness & Liveness, yang berfungsi:

  • mengetahui pod sudah siap untuk diakses atau belum
  • mengetahui jika pod tidak bisa diakses pada waktu tertentu ketika pod sudah berjalan

dari kegunaan tersebut pod yang tidak bisa diakses akan otomatis recreate(dibuat ulang) sesuai dengan parameter yang kita tentukan.

Link terkait Readiness & Liveness

Kelima | Rolling Update (Optional&improvement)

Pada dasarnya untuk metode deployment rolling update sudah ada secara default. Namun sebelum itu kita perlu paham terlebih dahulu apa itu maxSurge dan maxUnavailable. maxSurge berfungsi untuk mengatur berapa banyak pod yang akan kita tambahkan ketika terjadi update. maxUnavailable berfungsi untuk mengatur berapa banyak pod yang akan dihilangkan ketika proses rolling update.

Masing-masing antara maxSurge dan maxUnavailable bisa diatur menggunakan persentase maupun jumlah pod.

Link terkait Rolling Update (maxSurge & max unavailable)