Resource Management #

Di dalam kluster Kubernetes tingkat produksi, alokasi sumber daya komputasi seperti CPU dan memori adalah faktor terpenting yang menentukan stabilitas aplikasi dan efisiensi biaya infrastruktur. Jika kita membiarkan kontainer aplikasi berjalan tanpa pengaturan sumber daya yang terencana, kita sedang meletakkan bom waktu di dalam kluster. Kontainer yang tidak dibatasi dapat melahap seluruh memori fisik Node, menyebabkan pod lain di sekitarnya mati secara mendadak (noisy neighbor effect), atau bahkan memicu kegagalan total pada sistem operasi host (kernel panic). Sebaliknya, menyetel alokasi secara berlebihan demi keamanan sesaat akan membuang-buang anggaran cloud karena banyak kapasitas komputasi yang dibayar namun tidak pernah digunakan. Resource Management adalah disiplin untuk menyeimbangkan kebutuhan ini secara deklaratif. Artikel ini membahas secara mendalam konsep Requests vs Limits, karakteristik alokasi CPU dan memori, klasifikasi Quality of Service (QoS), implementasi kebijakan default via LimitRange, pembatasan kuota via ResourceQuota, hingga teknik penentuan nilai berbasis data observabilitas.

Konsep Requests vs Limits #

Kubernetes membagi definisi alokasi sumber daya kontainer menjadi dua parameter utama: Requests dan Limits. Kedua parameter ini memiliki peran yang sangat berbeda pada fase penjadwalan (scheduling) dan fase eksekusi (runtime).

+-------------------------------------------------------------------------+
|                              LIMITS                                     |
|   - Batas atas penyerapan komputasi kontainer di fase Runtime           |
|   - CPU: Throttling (CFS quota) jika terlampaui                         |
|   - Memory: Pod di-OOMKilled secara instan jika terlampaui              |
+-------------------------------------------------------------------------+
|                              REQUESTS                                   |
|   - Slot minimum yang dijamin tersedia di fase Scheduling               |
|   - Digunakan kube-scheduler untuk memilih Node fisik                   |
|   - Dihitung dari kapasitas "Allocatable" pada Node                     |
+-------------------------------------------------------------------------+

1. Resource Requests (Fase Penjadwalan) #

Requests menentukan jumlah minimum CPU dan memori yang dijamin pasti tersedia untuk kontainer. Ketika kita mengirimkan manifest Pod, kube-scheduler akan memindai seluruh Node aktif dan menghitung sisa kapasitas komputasi yang dapat dialokasikan (Allocatable Capacity).

Scheduler hanya akan menempatkan Pod pada Node yang memiliki sisa kapasitas yang lebih besar atau sama dengan total Requests dari Pod tersebut. Jika tidak ada Node yang mampu memenuhi syarat Requests, Pod akan terjebak dalam status Pending dengan pesan galat Insufficient CPU atau Insufficient Memory.

[!IMPORTANT] Requests bukanlah representasi dari seberapa banyak CPU atau memori yang sedang digunakan secara aktif saat ini (active usage). Requests adalah reservasi kapasitas statis. Meskipun kontainer kita sedang idle dan hanya mengonsumsi 5MB memori, Kubernetes tetap akan mengunci slot memori sesuai nilai Requests (misal 512MB) pada Node tersebut agar tidak dapat ditempati oleh Pod lainnya.

2. Resource Limits (Fase Runtime) #

Limits menentukan batas atas maksimum sumber daya yang boleh dikonsumsi oleh kontainer selama masa operasionalnya. Ketika kontainer mulai berjalan, kernel Linux di tingkat host (melalui mekanisme cgroups atau Control Groups) akan membatasi penyerapan daya kontainer agar tidak melebihi batas Limits.

Perilaku sistem saat kontainer mencoba melewati batas Limits sangat bervariasi tergantung pada jenis sumber dayanya:

A. CPU (Compressible Resource) #

CPU dikategorikan sebagai compressible resource karena alokasi waktu pemrosesannya dapat dipadatkan secara dinamis. Jika sebuah kontainer mencoba mengonsumsi CPU melebihi batas Limits-nya, kernel Linux tidak akan mematikan kontainer tersebut.

Sebagai gantinya, kernel akan menerapkan CPU Throttling (melalui CFS Bandwidth Control). Kontainer akan dipaksa menunggu giliran waktu pemrosesan (CPU cycles). Akibatnya, performa aplikasi kita akan menurun drastis, latensi transaksi HTTP meningkat, dan respons sistem menjadi lambat, namun kontainer tetap berjalan.

B. Memori (Incompressible Resource) #

Memori dikategorikan sebagai incompressible resource karena data yang disimpan di RAM tidak dapat dipadatkan secara instan tanpa merusak integritas proses. Jika sebuah kontainer mencoba menggunakan memori melebihi batas Limits-nya, kernel Linux akan langsung bertindak tegas dengan mematikan kontainer tersebut melalui mekanisme Out Of Memory (OOM) Killer.

Kontainer akan mati secara instan dengan kode keluar (exit code) 137 dan status Pod akan berubah menjadi OOMKilled.

Analogi Sederhana Manajemen Resource #

Untuk mempermudah pemahaman tim pengembang, kita dapat menggunakan analogi pemesanan meja di restoran:

Requests adalah jumlah kursi yang kita pesan secara resmi sebelum datang ke restoran. Restoran menjamin kursi tersebut pasti tersedia untuk kita saat kita tiba.
Limits adalah jumlah maksimal makanan yang diizinkan untuk kita pesan berdasarkan anggaran kartu kredit kita.
CPU Throttling seperti pelayan restoran yang memperlambat penyajian makanan karena kita makan terlalu cepat melebihi paket standar kita. Kita tidak diusir, hanya harus menunggu lebih lama.
OOMKilled seperti petugas keamanan restoran yang langsung mengusir kita keluar dari pintu restoran secara paksa karena kita mencoba mengambil makanan dari meja pelanggan lain setelah batas maksimal anggaran kita habis.

Quality of Service (QoS) Classes dan Hierarki Eviksi #

Kubernetes secara otomatis mengelompokkan Pod ke dalam salah satu dari tiga kelas Quality of Service (QoS) berdasarkan konfigurasi Requests dan Limits yang kita tulis. Kelas QoS ini menentukan prioritas eviksi (eviction priority) ketika sebuah Node mengalami krisis memori atau kehabisan ruang disk (Node Pressure).

Berikut adalah alur evakuasi pod berdasarkan klasifikasi QoS saat terjadi krisis sumber daya di Node:

flowchart TD
    NodePressure["1. Terjadi Tekanan Sumber Daya (Node Memory/Disk Pressure)"] --> CheckQoS["2. Pindai QoS Class Semua Pod di Node"]
    CheckQoS --> BestEffortList["3. Kategori: BestEffort (Tidak ada Requests/Limits)"]
    BestEffortList -->|"Evikasi Pertama (OOM Score 1000)"| EvictBestEffort["4. Evakuasi & Hancurkan Pod BestEffort"]
    
    EvictBestEffort --> CheckPressure{"5. Apakah Tekanan Mereda?"}
    CheckPressure -- "Ya" --> EndEviction["6. Hentikan Evikasi (Kluster Stabil)"]
    CheckPressure -- "Tidak" --> BurstableList["7. Kategori: Burstable (Requests < Limits)"]
    
    BurstableList -->|"Evikasi Kedua (OOM Score Berbasis Persentase Usage)"| EvictBurstable["8. Evakuasi Pod Burstable dengan Konsumsi Melebihi Request"]
    EvictBurstable --> CheckPressure2{"9. Apakah Tekanan Mereda?"}
    CheckPressure2 -- "Ya" --> EndEviction
    CheckPressure2 -- "Tidak" --> GuaranteedList["10. Kategori: Guaranteed (Requests == Limits)"]
    
    GuaranteedList -->|"Evikasi Terakhir (OOM Score Minimum)"| EvictGuaranteed["11. Terpaksa Evakuasi Pod Guaranteed (Kondisi Kritis)"]
    EvictGuaranteed --> EndEviction

1. Guaranteed QoS (Paling Aman) #

Pod mendapatkan klasifikasi Guaranteed jika dan hanya jika kita menentukan nilai Requests dan Limits dengan angka yang persis sama untuk seluruh kontainer di dalam Pod tersebut (berlaku untuk CPU dan memori).

# Pod dengan QoS Guaranteed
spec:
  containers:
  - name: api-container
    resources:
      requests:
        cpu: "500m"
        memory: "512Mi"
      limits:
        cpu: "500m"      # Wajib sama dengan requests
        memory: "512Mi"  # Wajib sama dengan requests

Prioritas Eviksi: Paling rendah. Kubernetes memprioritaskan Pod ini untuk tetap hidup. Pod Guaranteed hanya akan dieviksi jika Node mengalami kondisi krisis ekstrem dan seluruh Pod BestEffort serta Burstable sudah habis dihancurkan.
OOM Score: Dinilai dengan nilai minimum (biasanya -997 hingga 0), membuat kernel Linux host enggan mematikannya.

2. Burstable QoS (Menengah) #

Pod diklasifikasikan sebagai Burstable jika kita menentukan Limits yang lebih besar dari nilai Requests, atau jika kita hanya menentukan salah satu parameter saja (misalnya menentukan Requests tanpa Limits).

# Pod dengan QoS Burstable (Umum digunakan)
spec:
  containers:
  - name: api-container
    resources:
      requests:
        cpu: "200m"
        memory: "256Mi"
      limits:
        cpu: "1000m"     # Diizinkan melakukan burst hingga 1 Core saat idle
        memory: "512Mi"  # Limit memori disetel konservatif

Prioritas Eviksi: Menengah. Jika Node mulai tertekan, Kubernetes akan memilah Pod Burstable. Pod Burstable yang mengonsumsi memori melebihi kapasitas Requests-nya akan dieviksi terlebih dahulu dibandingkan Pod Burstable yang masih mengonsumsi memori di bawah nilai Requests-nya.
OOM Score: Dihitung secara dinamis berdasarkan persentase memori yang diminta terhadap kapasitas memori Node.

3. BestEffort QoS (Paling Berisiko) #

Pod masuk ke kelas BestEffort jika kita tidak menuliskan konfigurasi requests dan limits sama sekali di seluruh kontainernya.

# Pod dengan QoS BestEffort (Sangat Berbahaya untuk Produksi!)
spec:
  containers:
  - name: debug-tool
    # Tidak ada blok 'resources' sama sekali!

Prioritas Eviksi: Paling tinggi. Begitu Node mengalami tekanan memori terkecil sekalipun, Kubernetes akan langsung mematikan Pod BestEffort secara paksa tanpa ampun untuk membebaskan RAM Node.
OOM Score: Dinilai dengan angka maksimal 1000, menjadikannya sasaran empuk pertama bagi OOM Killer kernel Linux.

Menentukan Nilai Alokasi Berbasis Data Observabilitas #

Menentukan nilai Requests dan Limits tidak boleh dilakukan menggunakan tebakan insting developer (guesswork). Kita harus menggunakan data historis penggunaan sumber daya aplikasi yang tercatat di Prometheus.

Kueri PromQL untuk Pengambilan Data Histori #

Gunakan kueri PromQL berikut di dasbor Prometheus atau Grafana Anda untuk menganalisis karakteristik aplikasi selama 24 jam atau 7 hari terakhir:

1. Menghitung Rata-Rata Penggunaan CPU (Untuk Dasar Penentuan Requests) #

Kueri ini menghitung rata-rata penggunaan CPU kontainer untuk mengetahui konsumsi baseline harian.

# Rata-rata penggunaan CPU kontainer 'api-service' dalam 24 jam terakhir
avg_over_time(
  rate(container_cpu_usage_seconds_total{
    namespace="production", container="api-service"
  }[5m])[24h:]
)

2. Menghitung Persentil ke-95 (p95) Penggunaan CPU (Untuk Penentuan Limits) #

Kueri ini mendeteksi nilai konsumsi CPU pada kondisi beban kerja tinggi untuk mengantisipasi burst.

# Nilai p95 penggunaan CPU kontainer
quantile_over_time(0.95,
  rate(container_cpu_usage_seconds_total{
    namespace="production", container="api-service"
  }[5m])[24h:]
)

3. Menghitung Persentil ke-99 (p99) Penggunaan Memori (Untuk Penentuan Limits Memori) #

Memori bersifat incompressible, sehingga kita harus menggunakan persentil tinggi (p99) untuk menghindari OOMKilled saat lonjakan trafik.

# Nilai p99 penggunaan memori working set bytes
quantile_over_time(0.99,
  container_memory_working_set_bytes{
    namespace="production", container="api-service"
  }[24h:]
)

Rumus Praktis Penyetelan Awal (Rule of Thumb) #

Berdasarkan metrik di atas, gunakan rumus praktis berikut untuk menentukan alokasi awal sebelum merilis aplikasi ke produksi:

$$\text{CPU Requests} = \text{Rata-rata CPU harian} \times 1.20 \quad (\text{Buffer } 20%)$$ $$\text{Memory Requests} = \text{Rata-rata Memori harian} \times 1.30 \quad (\text{Buffer } 30%)$$ $$\text{Memory Limits} = \text{p99 Memori harian} \times 1.50 \quad (\text{Buffer Keamanan } 50%)$$

[!TIP] Rekomendasi Penyetelan Limits CPU: Di tingkat produksi, pertimbangkan untuk tidak menentukan CPU Limits (biarkan kosong) jika aplikasi Anda sensitif terhadap latensi transaksi dan Anda telah menerapkan limitasi melalui ResourceQuota di tingkat namespace. CPU Throttling akibat limits yang terlalu ketat sering kali menjadi penyebab misterius lambatnya respons aplikasi Java/Go, padahal kapasitas CPU fisik Node masih sangat longgar.

LimitRange: Proteksi Default di Tingkat Namespace #

Untuk mencegah adanya pengembang yang secara tidak sengaja mendeploy kontainer tanpa spesifikasi sumber daya (sehingga masuk ke QoS BestEffort), kita wajib menerapkan kebijakan LimitRange di setiap namespace aktif.

LimitRange secara otomatis akan menyisipkan nilai default Requests dan Limits jika manifest Pod yang dikirimkan tidak memilikinya.

# File: k8s/namespaces/production-limitrange.yaml
apiVersion: v1
kind: LimitRange
metadata:
  name: prod-default-limits
  namespace: prod-apps
spec:
  limits:
  - type: Container
    # Menyisipkan Limits otomatis jika dikosongkan pengembang
    default:
      cpu: "500m"
      memory: "512Mi"
    # Menyisipkan Requests otomatis jika dikosongkan
    defaultRequest:
      cpu: "200m"
      memory: "256Mi"
    # Membatasi nilai maksimal yang boleh dideklarasikan pengembang
    max:
      cpu: "4000m"
      memory: "8Gi"
    # Membatasi nilai minimal yang boleh dideklarasikan
    min:
      cpu: "50m"
      memory: "64Mi"
  - type: PersistentVolumeClaim
    min:
      storage: "1Gi"
    max:
      storage: "100Gi"

Jika pengembang mencoba mendeploy Pod dengan meminta memory: 16Gi (melebihi batas max LimitRange sebesar 8Gi), Kubernetes API Server akan langsung menolak proses deployment tersebut dengan pesan kesalahan validasi.

ResourceQuota: Pembatasan Total Kapasitas Tim #

Jika kluster kita digunakan bersama oleh beberapa tim (multi-tenant cluster), satu tim dapat secara tidak sengaja mendeploy puluhan Pod dengan Requests tinggi yang menghabiskan seluruh kapasitas fisik kluster, menyisakan nol kapasitas bagi tim lain.

ResourceQuota membatasi akumulasi jumlah sumber daya yang dapat dikonsumsi di satu namespace.

# File: k8s/namespaces/team-a-quota.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-resource-limits
  namespace: team-a-dev
spec:
  hard:
    # Batasan Akumulasi CPU & Memori Requests
    requests.cpu: "10"          # Maksimal total request 10 Cores CPU
    requests.memory: "20Gi"      # Maksimal total request 20 GiB RAM
    
    # Batasan Akumulasi CPU & Memori Limits
    limits.cpu: "20"
    limits.memory: "40Gi"
    
    # Batasan Jumlah Objek fisik di Namespace
    pods: "30"                  # Maksimal hanya boleh ada 30 Pod aktif
    services: "10"              # Maksimal 10 Service
    persistentvolumeclaims: "5" # Maksimal 5 PVC
    
    # Batasan Total Storage
    requests.storage: "100Gi"

Kita dapat memeriksa sisa kuota yang dapat digunakan oleh tim menggunakan perintah berikut:

# Menampilkan status limitasi quota aktif dan kapasitas yang terpakai
kubectl describe resourcequota team-a-resource-limits -n team-a-dev

Output deskripsi akan menyajikan perbandingan detail:

Resource             Used   Hard
--------             ---    ----
limits.cpu           4500m  20
limits.memory        9Gi    40Gi
pods                 12     30
requests.cpu         2200m  10
requests.memory      4.5Gi  20Gi

Vertical Pod Autoscaler (VPA) untuk Otomatisasi #

Mengelola nilai requests/limits secara manual untuk ratusan aplikasi mikroservis sangatlah melelahkan. Kita dapat memanfaatkan Vertical Pod Autoscaler (VPA) untuk menganalisis penggunaan aktual kontainer secara terus-menerus dan merekomendasikan atau menerapkan penyesuaian alokasi secara otomatis.

# File: k8s/production-vpa.yaml
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: payment-api-vpa
  namespace: prod-apps
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: payment-api
  updatePolicy:
    # Pilihan Mode:
    # - "Off": Hanya memberikan rekomendasi di status VPA, tidak merubah Pod (Sangat Direkomendasikan untuk Production)
    # - "Auto": Evict Pod lama secara otomatis dan buat baru dengan request/limit termutakhir (Menyebabkan restart Pod)
    updateMode: "Off"
  resourcePolicy:
    containerPolicies:
    - containerName: app-container
      minAllowed:
        cpu: "100m"
        memory: "128Mi"
      maxAllowed:
        cpu: "2000m"
        memory: "4Gi"

Untuk melihat rekomendasi ukuran kontainer yang dihasilkan oleh VPA:

# Membaca metrik rekomendasi penyesuaian kontainer
kubectl describe vpa payment-api-vpa -n prod-apps

Output status akan menampilkan rekomendasi target:

  Recommendation:
    Container Recommendations:
      Container Name:  app-container
      Lower Bound:
        Cpu:     150m
        Memory:  256Mi
      Target:            # Nilai request ideal hasil analisis VPA
        Cpu:     280m
        Memory:  380Mi
      Upper Bound:
        Cpu:     800m
        Memory:  768Mi

Anti-Pattern dalam Manajemen Sumber Daya #

Hindari dua kesalahan fatal berikut saat merancang alokasi sumber daya di kluster produksi:

1. Membiarkan Aplikasi Berjalan Tanpa Batasan (BestEffort Class) #

# ANTI-PATTERN: Deployment tanpa deklarasi sumber daya apapun
apiVersion: apps/v1
kind: Deployment
metadata:
  name: untracked-api
spec:
  template:
    spec:
      containers:
      - name: app
        image: app:latest # JANGAN: Pod masuk ke QoS BestEffort!

Risiko Operasional:
- Pod BestEffort akan langsung dimatikan secara paksa oleh kernel (OOMKilled) ketika Node mengalami kenaikan konsumsi RAM sekecil apapun.
- Ketiadaan requests membuat scheduler buta; Pod bisa dijadwalkan ke Node yang sebenarnya RAM fisiknya sudah habis terpakai oleh sistem operasi host, memicu kegagalan sistem Node.
✓ SOLUSI: Pasang LimitRange di namespace dan pastikan pipa CI/CD memvalidasi keberadaan parameter resources di setiap manifest YAML.

2. Overcommit Memori dengan Selisih Limit Terlalu Tinggi #

Mengonfigurasi nilai Requests memori yang sangat kecil namun menyetel Limits memori yang sangat besar demi menghindari galat OOMKilled tanpa kalkulasi matang.

# ANTI-PATTERN: Selisih Request dan Limit memori yang terlampau jauh
resources:
  requests:
    cpu: "100m"
    memory: "64Mi"   # Sangat Kecil
  limits:
    cpu: "1000m"
    memory: "16Gi"   # Sangat Besar (Overcommit berbahaya)

Risiko Operasional:
- Kubernetes Scheduler menjadwalkan Pod ini ke Node yang hanya memiliki sisa RAM Allocatable sebesar 512MB (karena request Pod hanya meminta 64MB).
- Saat aplikasi berjalan dan mengalami lonjakan beban kerja, ia meminta alokasi memori hingga 4GB.
- Karena batas limitnya adalah 16GB, kontainer merasa diizinkan menggunakan RAM tersebut. Namun, kapasitas fisik Node hanya tersisa 512MB.
- Akibatnya, Node fisik akan mengalami kehabisan memori total (Out-Of-Memory). Kernel Linux host terpaksa mematikan proses sistem operasi kritis, menyebabkan Node berstatus 'NotReady' dan mematikan seluruh Pod lain yang bertetangga dengannya.
✓ SOLUSI: Jaga rasio batas memori requests vs limits tidak lebih dari 1:2 untuk lingkungan produksi, atau gunakan QoS Guaranteed (1:1) untuk kestabilan penuh.

Checklist Audit Resource Management #

Lakukan audit menyeluruh pada kluster produksi Anda menggunakan panduan checklist berikut:

PENGATURAN REQUESTS & LIMITS:
  □ Tidak ada Pod di namespace produksi yang berjalan dengan QoS Class 'BestEffort' (tanpa spec resource).
  □ Nilai Requests ditentukan berdasarkan data historis penggunaan riil (bukan dugaan/insting).
  □ Rasio alokasi Memori requests vs limits berada dalam batas aman (maksimal rasio 1:2 untuk Burstable).
  □ Workload kritis seperti database utama dikonfigurasi menggunakan QoS Class 'Guaranteed'.
  □ CPU Limits dikonfigurasi secara hati-hati (atau dikosongkan) untuk menghindari latensi akibat CPU Throttling.

PROTEKSI NAMESPACE & DEFAULT:
  □ Setiap namespace aktif memiliki objek 'LimitRange' untuk menyisipkan nilai default CPU/RAM.
  □ Objek 'ResourceQuota' terpasang di setiap namespace multi-tenant untuk membatasi konsumsi akumulasi CPU/RAM.
  □ Kebijakan ResourceQuota mencakup batasan jumlah objek kritis (Pods, PVCs, Services).
  □ Quota penyimpanan dikonfigurasi secara spesifik berdasarkan kelas penyimpanan (StorageClass).

MONITORING DAN AUTOSCALING:
  □ Kueri PromQL untuk p95 CPU dan p99 Memory dipantau secara berkala melalui dasbor Grafana.
  □ Vertical Pod Autoscaler (VPA) terpasang dalam mode 'Off' untuk memberikan rekomendasi right-sizing harian.
  □ Notifikasi alarm aktif untuk mendeteksi kontainer yang mendekati batas limits memori (>90% memory usage).
  □ Menjalankan pengujian beban kerja (*load testing*) untuk memvalidasi performa CPU throttling kontainer.

Ringkasan #

Request untuk Penjadwalan, Limit untuk Runtime — Pahami perbedaannya; scheduler menggunakan requests untuk memilih Node, sedangkan kernel host menggunakan limits untuk membatasi konsumsi kontainer secara fisik.

Waspadai Dampak OOMKilled — Ingat bahwa melampaui limits memori memicu kematian instan kontainer (OOMKilled - exit code 137), sedangkan melampaui limits CPU hanya memicu penurunan performa (throttling).

Terapkan QoS Guaranteed untuk DB — Konfigurasikan requests dan limits dengan nilai yang identik untuk pod database penting agar mendapatkan prioritas eviksi terendah dari Kubernetes.

Gunakan LimitRange sebagai Pengaman — Pasang objek LimitRange di tingkat namespace untuk mengamankan kluster dari kelalaian pengembang yang lupa menulis spesifikasi sumber daya kontainer.

Cegah Monopoli dengan ResourceQuota — Batasi akumulasi sumber daya CPU/RAM per tim di tingkat namespace menggunakan ResourceQuota demi keadilan alokasi sumber daya.

Hindari Overcommit Memori Ekstrem — Jaga rasio memori requests vs limits tetap rasional untuk melindungi Node fisik dari ancaman kehabisan memori total (host memory starvation).

← Sebelumnya: Anti-Pattern Ecosystem & Tooling Berikutnya: Autoscaling →