KAL
Menu

Metrik

metrics-server, perintah kubectl top, dan loop umpan balik pengaturan sumber daya.

Daftar isi

Nilai request dan limit yang tertulis di manifest merupakan hipotesis tentang kebutuhan aplikasi, dan metrik pemakaian adalah data yang membuktikannya. Topik ini membahas metrics-server sebagai penyedia metrik di dalam kluster, pembacaan hasilnya dengan kubectl top, serta loop umpan balik yang mengubah data pemakaian menjadi penyesuaian request dan limit. Setelah membacanya, nilai request dan limit pada manifest dapat dinilai ulang berdasarkan data pemakaian yang benar-benar terjadi.

metrics-server sebagai penyedia metrik#

metrics-server adalah komponen kluster yang mengumpulkan penggunaan CPU dan memori dari kubelet di setiap Node melalui Summary API, lalu menyajikannya melalui API agregat metrics.k8s.io. Dua konsumen utamanya adalah perintah kubectl top dan HorizontalPodAutoscaler, yang keduanya membaca metrik dari jalur yang sama. Alur datanya tersusun tiga lapis. Kubelet mengumpulkan statistik dari container di Node-nya, metrics-server menarik ringkasan tersebut dari seluruh kubelet secara berkala, dan API agregat menyajikannya kepada klien dengan bentuk yang sama seperti API kluster lainnya.

Dengan pola ini, klien tidak perlu menjangkau setiap Node sendiri dan cukup bertanya kepada API server, sementara kebijakan hak akses tetap berlaku karena pembacaan dilakukan melalui API yang sama. Penyimpanan metrics-server berada di memori prosesnya dengan jendela waktu pendek, sehingga nilai yang ditawarkan adalah potret beberapa menit terakhir, bukan riwayat berhari-hari.

Pada kluster belajar minikube, metrics-server diaktifkan sebagai addon, sedangkan kluster produksi umumnya sudah memasangnya sejak awal karena HorizontalPodAutoscaler membutuhkannya.

bash 
# tidak-dijalankan
# mengaktifkan metrics-server pada kluster minikube
minikube addons enable metrics-server
# memastikan deployment metrics-server berjalan di namespace kube-system
kubectl get deployment metrics-server -n kube-system
text Contoh keluaran 
NAME             READY   UP-TO-DATE   AVAILABLE   AGE
metrics-server   1/1     1            1           3m

Membaca pemakaian dengan kubectl top#

Perintah kubectl top nodes menampilkan pemakaian agregat per Node, sedangkan kubectl top pods menampilkan pemakaian per Pod. CPU dicetak dalam milicore dengan 1000m berarti satu core penuh, dan memori dicetak dalam MiB. Kolom persentase pada kubectl top nodes dihitung terhadap kapasitas yang dapat dialokasikan untuk Pod, bukan terhadap seluruh kapasitas fisik Node, sehingga angkanya dapat dibaca langsung sebagai pemakaian beban kerja.

bash 
# tidak-dijalankan
# menampilkan pemakaian CPU dan memori per Node
kubectl top nodes
text Contoh keluaran 
NAME      CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
node-01   312m         16%    2048Mi          27%
node-02   148m         7%     1523Mi          20%
bash 
# tidak-dijalankan
# menampilkan pemakaian per Pod diurutkan dari CPU tertinggi
kubectl top pods -n aplikasi-catatan --sort-by=cpu
text Contoh keluaran 
NAME                          CPU(cores)   MEMORY(bytes)
catatan-api-7d9c4b6d5f-xk2qz  470m         90Mi
catatan-api-7d9c4b6d5f-wm8pb  180m         95Mi
catatan-web-6b8f4d7c9d-t5rk2  20m          28Mi

Angka pada keluaran top baru bermakna apabila dibandingkan dengan request yang tertulis di manifest. Pod catatan-api pertama menampilkan 470m, sedangkan request CPU-nya 250m. Artinya, pemakaian hampir mencapai dua kali request. Kondisi seperti ini tidak langsung berbahaya, tetapi menjadi sinyal bahwa hipotesis awal tentang kebutuhan aplikasi perlu dikoreksi. Untuk melihat keduanya berdampingan, angka top dibandingkan dengan request melalui perintah kubectl get pods dengan -o custom-columns, misalnya kolom nama, request CPU, dan pemakaian CPU. Perbandingan manual ini memadai untuk pemeriksaan sesaat, sedangkan perhitungan berulang lebih praktis dilakukan oleh skrip sebagaimana dipraktikkan pada bagian berikutnya.

Loop umpan balik request dan limit#

Penyesuaian request dan limit berjalan sebagai loop yang berulang. Langkahnya berbunyi: ukur pemakaian dengan kubectl top, bandingkan dengan request pada manifest, sesuaikan nilai yang menyimpang, lakukan rollout, lalu ukur lagi setelah beberapa hari. Aturan praktis yang lazim berbunyi: pemakaian CPU yang stabil di atas 80% dari request menandakan risiko pembatasan oleh kernel, memori yang mendekati limit berisiko berakhir dengan status OOMKilled, dan pemakaian yang dalam jangka panjang berada di bawah seperempat request menandakan sumber daya yang terbuang.

Berkas berikut meniru keluaran kubectl top untuk satu namespace, lengkap dengan request masing-masing Pod.

json top.json 
{
  "namespace": "aplikasi-catatan",
  "pod": [
    {
      "nama": "catatan-api-7d9c4b6d5f-xk2qz",
      "cpu_milicore": 470,
      "request_cpu_milicore": 250,
      "memori_mib": 90,
      "request_memori_mib": 256
    },
    {
      "nama": "catatan-api-7d9c4b6d5f-wm8pb",
      "cpu_milicore": 180,
      "request_cpu_milicore": 250,
      "memori_mib": 95,
      "request_memori_mib": 256
    },
    {
      "nama": "catatan-web-6b8f4d7c9d-t5rk2",
      "cpu_milicore": 20,
      "request_cpu_milicore": 100,
      "memori_mib": 28,
      "request_memori_mib": 128
    }
  ]
}

Skrip berikut menghitung persentase pemakaian terhadap request dan menandai Pod yang memerlukan penyesuaian.

python Contoh: menandai Pod yang perlu disesuaikan 
import json

# membaca sampel pemakaian yang meniru keluaran kubectl top
data = json.load(open("top.json", encoding="utf-8"))
AMBANG_TINGGI = 80   # persen request
AMBANG_RENDAH = 25   # persen request

for pod in data["pod"]:
    cpu_persen = pod["cpu_milicore"] / pod["request_cpu_milicore"] * 100
    mem_persen = pod["memori_mib"] / pod["request_memori_mib"] * 100
    # menentukan arah penyesuaian dari dua sumber daya
    catatan = []
    if cpu_persen > AMBANG_TINGGI:
        catatan.append("CPU di atas ambang 80%, request CPU dinaikkan")
    if mem_persen > AMBANG_TINGGI:
        catatan.append("memori di atas ambang 80%, request memori dinaikkan")
    if cpu_persen < AMBANG_RENDAH and mem_persen < AMBANG_RENDAH:
        catatan.append("jauh di bawah request, nilai bisa diturunkan")
    if not catatan:
        catatan.append("sesuai request")
    print(f"{pod['nama']}: CPU {cpu_persen:.0f}% dari request, memori {mem_persen:.0f}% dari request")
    for baris in catatan:
        print(f"  - {baris}")
text Keluaran 
catatan-api-7d9c4b6d5f-xk2qz: CPU 188% dari request, memori 35% dari request
  - CPU di atas ambang 80%, request CPU dinaikkan
catatan-api-7d9c4b6d5f-wm8pb: CPU 72% dari request, memori 37% dari request
  - sesuai request
catatan-web-6b8f4d7c9d-t5rk2: CPU 20% dari request, memori 22% dari request
  - jauh di bawah request, nilai bisa diturunkan

Keluaran di atas mendasari tiga keputusan yang berbeda. Request CPU replika pertama perlu dinaikkan, replika kedua dibiarkan, dan request catatan-web dapat diturunkan agar penjadwalan menjadi lebih efisien. Satu catatan penting menyertai keputusan ini: angka top merupakan potret sesaat, sehingga penyesuaian yang sehat didasarkan pada tren pemakaian, bukan satu sampel tunggal.

Batas metrik dan pemantauan jangka panjang#

Karena metrics-server hanya menyimpan nilai terkini, loop di atas tidak dapat berjalan hanya dengan kubectl top pada kluster produksi. Pemantauan jangka panjang menggunakan sistem terpisah, misalnya Prometheus, yang menarik metrik dari kubelet dan API server secara berkala lalu menyimpan riwayatnya untuk digambar menjadi grafik dan digunakan untuk peringatan otomatis. Arsitektur lengkapnya dijelaskan pada dokumentasi monitoring Kubernetes.

Perbedaan tujuan ini menjelaskan pembagian perannya. metrics-server melayani pertanyaan sesaat dan kebutuhan HorizontalPodAutoscaler yang hanya membaca nilai terkini, sedangkan sistem pemantauan menyimpan deret waktu yang memungkinkan tren mingguan, peringatan berbasis ambang, dan perbandingan antarhari. Tanpa sistem pemantauan, penyesuaian request berisiko mengikuti sampel sesaat, misalnya menaikkan request karena lonjakan pada satu jam sibuk lalu membiarkannya berlebihan selama sisa hari. Di samping sistem pemantauan tersebut, kubectl top tetap berguna karena cepat dan tersedia di setiap kluster yang memiliki metrics-server, sehingga kombinasi yang lazim berbunyi: kubectl top untuk pemeriksaan langsung saat kejadian, sistem pemantauan untuk tren dan peringatan, serta loop umpan balik yang sama untuk menjaga request dan limit tetap sesuai dengan perilaku aplikasi.

Ringkasan#

  • metrics-server mengumpulkan penggunaan CPU dan memori dari kubelet dan menyajikannya melalui API metrics.k8s.io untuk kubectl top dan HorizontalPodAutoscaler.
  • kubectl top nodes dan kubectl top pods menampilkan pemakaian dalam milicore serta MiB, dan nilainya baru bermakna apabila dibandingkan dengan request.
  • Penyesuaian request dan limit berjalan sebagai loop ukur, bandingkan, ubah, dan rollout dengan ambang praktis seperti 80% dari request.
  • metrics-server bukan penyimpanan riwayat, sehingga analisis tren memerlukan sistem pemantauan terpisah.

Referensi#