Penskalaan

Penskalaan jumlah replika secara manual dan pengenalan HorizontalPodAutoscaler untuk skala otomatis.

Daftar isi

Jumlah replika bukan nilai yang dibekukan saat deploy. Kubernetes menyediakan dua jalur penskalaan, yaitu perubahan manual yang dikendalikan pengguna dan penskalaan otomatis yang dihitung controller dari metrik beban. Topik ini membahas perintah kubectl scale, penyesuaian manifest sebagai sumber kebenaran, serta pengenalan HorizontalPodAutoscaler beserta rumus perhitungannya.

Penskalaan manual dengan kubectl scale#

Perintah kubectl scale mengubah bidang spec.replicas langsung di API server tanpa menyunting manifest. Deployment meneruskan nilai tersebut ke ReplicaSet aktifnya, dan rekonsiliasi ReplicaSet membuat atau menghapus Pod sampai jumlah yang baru tercapai. Penaikan replika menambah kapasitas segera setelah Pod siap, sedangkan penurunan memilih Pod yang akan dihapus dan menunggu Pod tersebut berhenti dengan rapi.

Penskalaan melalui perintah ini cepat, tetapi menciptakan dua sumber kebenaran. Nilai di kluster sudah enam, sedangkan manifest di repository masih menyebut lima. Penerapan ulang manifest berikutnya akan menimpa hasil kubectl scale, sehingga jumlah replika kembali ke nilai lama tanpa peringatan. Disiplin yang sehat adalah menjadikan manifest satu-satunya tempat perubahan jumlah replika, yaitu menyunting nilai replicas di sana dan menerapkannya kembali dengan kubectl apply.

bash
# tidak-dijalankan
# naikkan jumlah replika menjadi enam
kubectl scale deployment catatan --replicas=6

# periksa keadaan Deployment setelah penskalaan
kubectl get deploy catatan
text Contoh keluaran
deployment.apps/catatan scaled
NAME      READY   UP-TO-DATE   AVAILABLE   AGE
catatan   6/6     6            6           3m

Keluaran memperlihatkan perintah scale diikuti keadaan Deployment dengan enam dari enam Pod siap. Pesan scaled menandakan API server telah menerima perubahan jumlahnya, sedangkan kolom READY mengonfirmasi bahwa Pod tambahan sudah siap melayani. Perintah ini tidak menyentuh template Pod, sehingga tidak ada revisi baru yang tercipta pada peristiwa tersebut.

HorizontalPodAutoscaler#

HorizontalPodAutoscaler, biasa disingkat HPA, adalah objek yang mengatur jumlah replika secara otomatis berdasarkan metrik beban. Pengaturannya bersifat horizontal karena menambah jumlah Pod, bukan kapasitas satu Pod yang disebut penskalaan vertikal. HPA secara berkala membaca metrik, menghitung jumlah replika yang disarankan, lalu menulis nilainya ke bidang spec.replicas pada Deployment sasarannya.

Sumber metrik paling umum adalah penggunaan CPU rata-rata yang dinyatakan sebagai persentase dari request CPU Pod. Metrik lain seperti memori atau metrik kustom dapat ditambahkan sesuai kebutuhan. Dua batas menjaga perilakunya, yaitu minReplicas dan maxReplicas, sehingga jumlah replika tidak pernah di bawah nilai minimum maupun di atas nilai maksimum.

Manifest HPA menyatakan sasarannya pada scaleTargetRef beserta metrik dan batasnya. Target bertipe Utilization dengan nilai averageUtilization: 60 berarti HPA menjaga penggunaan CPU rata-rata di sekitar 60 persen dari request CPU Pod:

yaml hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: catatan
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: catatan
  minReplicas: 2
  maxReplicas: 8
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60

Metrik CPU tidak tersedia tanpa komponen pemantauan sumber daya di kluster. metrics-server atau penyedia metrik serupa harus terpasang terlebih dahulu, dan penyiapan komponen tersebut termasuk pekerjaan operasi kluster yang berada di luar lingkup topik ini. Tanpa sumber metrik, kolom TARGETS pada kubectl get hpa menampilkan nilai yang tidak diketahui dan penghitungan replika tidak berjalan.

bash
# tidak-dijalankan
# terapkan manifest HPA ke kluster
kubectl apply -f hpa.yaml

# periksa keadaan HPA beserta metrik yang terbaca
kubectl get hpa
text Contoh keluaran
horizontalpodautoscaler.autoscaling/catatan created
NAME      REFERENCE            TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
catatan   Deployment/catatan   cpu: 62%  2         8         4          5m

Kolom TARGETS menunjukkan penggunaan CPU yang terbaca dibandingkan targetnya, sedangkan REPLICAS adalah jumlah replika yang sedang dijalankan. Nilai MINPODS dan MAXPODS berasal langsung dari manifest, dan kolom REFERENCE menyebut objek yang diatur oleh HPA ini. Kolom AGE mengingatkan sejak kapan HPA aktif, sehingga perubahan perilakunya dapat dikaitkan dengan waktu penerapannya.

Rumus perhitungan HPA#

HPA menentukan jumlah replika dengan satu rumus. Nilai yang disarankan adalah jumlah replika sekarang dikalikan dengan rasio metrik terhadap target, lalu dibulatkan ke atas. Dalam bentuk matematika:

replika disarankan=⌈replika sekarang×metrik saat inimetrik target⌉ \text{replika disarankan} = \left\lceil \text{replika sekarang} \times \frac{\text{metrik saat ini}}{\text{metrik target}} \right\rceil

Controller menambahkan toleransi 0,1 agar jumlah replika tidak berkedip pada beban yang hampir stabil. Apabila rasio metrik berada dalam selisih sepuluh persen dari target, HPA membiarkan jumlah replika tetap. Penyesuaian hanya dijalankan apabila rasio melewati toleransi tersebut.

Simulasi berikut mengevaluasi lima skenario dengan target CPU 60 persen, batas minimum dua replika, dan batas maksimum delapan replika:

python
import math

TARGET = 60      # target penggunaan CPU dalam persen
BATAS_MIN = 2    # minReplicas
BATAS_MAKS = 8   # maxReplicas
TOLERANSI = 0.1  # selisih rasio yang dianggap masih stabil

def rencana(aktual: int, cpu: int) -> tuple[int, str]:
    """Terapkan rumus HPA beserta toleransi dan batasnya."""
    rasio = cpu / TARGET
    if abs(rasio - 1) <= TOLERANSI:
        return aktual, "jumlah tetap"
    disarankan = math.ceil(aktual * rasio)
    if disarankan > BATAS_MAKS:
        return BATAS_MAKS, "dibatasi maxReplicas"
    if disarankan < BATAS_MIN:
        return BATAS_MIN, "dibatasi minReplicas"
    return disarankan, "disesuaikan"

SKENARIO = [
    (4, 90),   # beban tinggi
    (4, 62),   # hampir pada target
    (6, 30),   # beban rendah
    (8, 200),  # lonjakan ekstrem
    (2, 10),   # beban nyaris kosong
]

for replika, cpu in SKENARIO:
    hasil, status = rencana(replika, cpu)
    print(f"CPU {cpu:>3}% pada {replika} replika -> {hasil} replika ({status})")
text Keluaran
CPU  90% pada 4 replika -> 6 replika (disesuaikan)
CPU  62% pada 4 replika -> 4 replika (jumlah tetap)
CPU  30% pada 6 replika -> 3 replika (disesuaikan)
CPU 200% pada 8 replika -> 8 replika (dibatasi maxReplicas)
CPU  10% pada 2 replika -> 2 replika (dibatasi minReplicas)

Skenario pertama dan ketiga memperlihatkan arah penskalaan yang wajar, yaitu CPU 90 persen menaikkan jumlah replika menjadi enam dan CPU 30 persen menurunkannya menjadi tiga. Skenario dengan CPU 62 persen tidak berubah karena selisihnya masih di dalam toleransi. Dua skenario terakhir menunjukkan peran batas, yaitu kebutuhan 27 replika dipangkas menjadi delapan oleh maxReplicas dan kebutuhan satu replika ditahan pada dua oleh minReplicas.

Perhitungan ini diulang pada setiap periode penyesuaian, dan metrik yang dibaca adalah rata-rata seluruh Pod sasaran. Satu Pod yang sedang sibuk dengan sendirinya tidak menggandakan jumlah replika, karena keadaannya terbaur dalam rata-rata Pod lain yang tenang. Perilaku ini membuat HPA cocok untuk beban yang merata antarpod, tetapi kurang efektif untuk beban yang terkonsentrasi pada satu Pod.

Kesalahan umum#

  • Menjalankan kubectl scale tanpa menyunting manifest membuat jumlah replika kembali ke nilai lama saat manifest diterapkan ulang. Perbaikannya, ubah spec.replicas di manifest dan terapkan kembali sebagai satu sumber kebenaran.
  • HPA dan kubectl scale yang digunakan bersamaan saling menimpa, karena keduanya menulis spec.replicas pada objek yang sama. Perbaikannya, serahkan jumlah replika sepenuhnya pada HPA dan hilangkan bidang replicas dari manifest Deployment.
  • HPA yang terpasang tanpa metrics-server tidak pernah mendapatkan metrik, sehingga statusnya gagal dan jumlah replika tidak berubah. Perbaikannya, pasang komponen pemantauan terlebih dahulu dan periksa kubectl describe hpa untuk melihat kondisi metriknya.

Ringkasan#

  • kubectl scale mengubah spec.replicas langsung di kluster, sedangkan manifest yang tidak ikut disunting akan menimpanya saat diterapkan ulang.
  • HorizontalPodAutoscaler menulis spec.replicas secara berkala dari perhitungan metrik, sehingga penskalaan manual dan otomatis tidak boleh berjalan pada objek yang sama.
  • Jumlah replika yang disarankan dihitung dari replika sekarang dikalikan dengan rasio metrik terhadap target, dibulatkan ke atas, dengan toleransi 0,1.
  • Batas minReplicas dan maxReplicas menahan hasil perhitungan, sedangkan metrik CPU menuntut metrics-server yang terpasang di kluster.

Referensi#