Apa perbedaan antara requests dan limits CPU/memory, dan bagaimana keduanya memengaruhi scheduling, eviction, dan QoS?

Question

IT Interview Practice · Accepted Answer

**Requests** adalah yang *dijamin* untuk sebuah container (dipakai untuk scheduling); **limits** adalah *batas atas* yang tidak boleh dilampaui (dipaksakan saat runtime). Bersama-sama keduanya menentukan di mana Pod ditempatkan, bagaimana ia di-throttle atau dibunuh saat tekanan, dan kelas **Quality of Service (QoS)** apa yang didapat sebuah Pod.

## Requests vs limits

```text
REQUEST → jumlah yang DICADANGKAN untuk container. SCHEDULER memakai total
          request untuk memutuskan apakah sebuah node punya ruang. Ini batas bawah terjamin Anda.
LIMIT   → MAKSIMUM yang boleh dipakai container. Dipaksakan saat runtime:
          CPU lewat limit    → THROTTLED (diperlambat, tidak dibunuh)
          memory lewat limit → OOM-KILLED (container dihentikan, lalu di-restart)
```

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      resources:
        requests:
          cpu: "250m"        # 0.25 core, terjamin
          memory: "256Mi"
        limits:
          cpu: "500m"        # boleh burst ke 0.5 core, lalu di-throttle
          memory: "512Mi"    # lewat ini → OOMKilled
```

## Bagaimana scheduling memakai requests

```text
Node punya 4 CPU / 8Gi allocatable.
Scheduler menjumlahkan REQUEST Pod yang sudah ditempatkan; Pod baru muat hanya jika
request-nya masih muat pada sisa yang ada. (Limit TIDAK dipakai untuk penempatan.)
→ Set request terlalu rendah → node overcommitted, Pod berebut resource.
→ Set request terlalu tinggi → kapasitas terbuang, Pod terjebak Pending (tak ada yang muat).
```

## Kelas QoS (menentukan urutan eviction saat tekanan memory)

```text
Guaranteed  → requests == limits untuk KEDUA cpu & memory (tiap container)
              → terakhir di-evict (prioritas tertinggi)
Burstable   → punya requests tapi < limits (atau diset sebagian)
              → di-evict setelah BestEffort
BestEffort  → tanpa requests atau limits sama sekali
              → PERTAMA di-evict saat node kehabisan memory
```

```bash
kubectl describe pod app | grep -i qos    # QoS Class: Guaranteed/Burstable/BestEffort
kubectl top pods                           # penggunaan CPU/memory sesungguhnya
kubectl describe node <node>               # resource yang dialokasikan vs kapasitas
```

## Panduan praktis

```text
✓ Selalu set memory requests = limits agar perilaku dapat diprediksi & aman-OOM pada app kritis
✓ Set CPU requests sesuai kebutuhan steady-state; CPU limits sering dibiarkan kosong agar bisa burst
✓ Sesuaikan ukuran dari penggunaan nyata (kubectl top / metrics) — bukan tebakan
✓ Pakai LimitRange / ResourceQuota untuk memaksakan default yang wajar per namespace
```

## Mengapa ini penting

Requests dan limits adalah cara Kubernetes membagi resource node yang terbatas secara adil dan dapat diprediksi, sehingga memahami perbedaannya dan konsekuensinya adalah pengetahuan performa dan keandalan yang esensial. Wawasan intinya adalah keduanya melayani tujuan berbeda: **requests** adalah cadangan terjamin yang dipakai **scheduler** untuk menempatkan Pod (menjumlahkan request untuk memutuskan apakah sebuah node punya ruang, mengabaikan limit), sedangkan **limits** adalah batas atas runtime yang dipaksakan berbeda per resource — melampaui limit **CPU** membuat Anda di-**throttle** (diperlambat), tetapi melampaui limit **memory** membuat container di-**OOM-kill** dan di-restart. Salah menyetel request punya biaya nyata di dua sisi: terlalu rendah dan node menjadi overcommitted sehingga Pod saling kelaparan; terlalu tinggi dan kapasitas terbuang sementara Pod terjebak Pending karena tak ada yang muat. Ketiga **kelas QoS** — Guaranteed (requests sama dengan limits), Burstable (requests di bawah limits), dan BestEffort (tak ada yang diset) — menentukan urutan eviction saat tekanan memory, dengan BestEffort dibunuh pertama dan Guaranteed terakhir, yang persis perlu Anda pahami untuk melindungi workload kritis. Mengetahui panduan praktisnya (set memory requests sama dengan limits untuk app kritis, sesuaikan ukuran dari penggunaan nyata via `kubectl top`, paksakan default dengan LimitRange/ResourceQuota) mengubah ini dari teori menjadi perencanaan kapasitas yang matang. Karena salah konfigurasi resource adalah salah satu penyebab paling umum ketidakstabilan, pemborosan biaya, dan Pod Pending di cluster nyata, menguasai requests, limits, dan QoS adalah fondasi untuk menjalankan workload Kubernetes yang efisien dan stabil.

Requests vs limits

Bagaimana scheduling memakai requests

Kelas QoS (menentukan urutan eviction saat tekanan memory)

Panduan praktis

Mengapa ini penting

Pertanyaan terkait