Apa bédané CPU/memory request lan limit, lan kepiyé pangaruhé marang scheduling, eviction, lan QoS?

Question

IT Interview Practice · Accepted Answer

**Request** yaiku apa sing *dijamin* marang sawijining container (dienggo kanggo scheduling); **limit** yaiku *plafon* sing ora kena diliwati (dipeksa nalika runtime). Bareng-bareng dhèwèké nggiring ngendi Pod disèlèhaké, kepiyé di-throttle utawa dipatèni ing tekanan, lan kelas **Quality of Service (QoS)** endi sing ditampa Pod.

## Request vs limit

```text
REQUEST → jumlah sing DICADANGAKÉ kanggo container. SCHEDULER nganggo jumlah total
          request kanggo mutusaké apa node isih ana panggonan. Iki lantai jaminan sampeyan.
LIMIT   → MAKSIMUM sing kena dienggo container. Dipeksa nalika runtime:
          CPU ngluwihi limit    → DI-THROTTLE (dilamban-lambanaké, ora dipatèni)
          memory ngluwihi limit → OOM-KILLED (container dipatèni, banjur di-restart)
```

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      resources:
        requests:
          cpu: "250m"        # 0.25 saka siji core, dijamin
          memory: "256Mi"
        limits:
          cpu: "500m"        # kena mbludak nganti 0.5 core, banjur di-throttle
          memory: "512Mi"    # ngluwihi iki → OOMKilled
```

## Kepiyé scheduling nganggo request

```text
Node nduwé 4 CPU / 8Gi allocatable.
Scheduler nJumlahaké REQUEST saka Pod sing wis disèlèhaké; Pod anyar mlebu mung yèn
request-é isih pas ing sisané. (Limit ORA dienggo kanggo panyèlèhan.)
→ Nyetel request kacilikan → node overcommitted, Pod rebutan resource.
→ Nyetel request kagedhèn → kapasitas kebuwang, Pod macet Pending (ora ana sing pas).
```

## Kelas QoS (nemtokaké urutan eviction ing tekanan memory)

```text
Guaranteed  → request == limit kanggo LORO-LORONÉ cpu & memory (saben container)
              → pungkasan sing di-evict (prioritas paling dhuwur)
Burstable   → nduwé request nanging luwih cilik saka limit (utawa disetel sabagéyan)
              → di-evict sawisé BestEffort
BestEffort  → ora ana request utawa limit babar pisan
              → SEPISANAN di-evict nalika node kentèkan memory
```

```bash
kubectl describe pod app | grep -i qos    # QoS Class: Guaranteed/Burstable/BestEffort
kubectl top pods                           # panganggoan CPU/memory nyata
kubectl describe node <node>               # resource sing dialokasi vs kapasitas
```

## Tuntunan praktis

```text
✓ Tansah setel memory request = limit kanggo prilaku sing bisa diprédhiksi, aman-OOM ing app kritis
✓ Setel CPU request menyang kabutuhan steady-state; CPU limit asring diilangi supaya bisa mbludak
✓ Right-size saka panganggoan nyata (kubectl top / metrics) — dudu tebakan
✓ Nganggo LimitRange / ResourceQuota kanggo meksa default sing waras saben namespace
```

## Kenapa iki penting

Request lan limit yaiku carané Kubernetes nuduhaké resource node sing winates kanthi adil lan bisa diprédhiksi, mula ngerti bédané lan akibaté yaiku kawruh performa lan keandalan sing penting. Wawasan intiné yaiku dhèwèké nglayani tujuan sing béda: **request** iku cadangan sing dijamin sing dienggo **scheduler** kanggo nyèlèhaké Pod (nJumlahaké request kanggo mutusaké apa node ana panggonan, ngabaikan limit), déné **limit** iku plafon runtime sing dipeksa béda saben resource — ngluwihi limit **CPU** njalari di-**throttle** (dilamban-lambanaké), nanging ngluwihi limit **memory** njalari container di-**OOM-kill** lan di-restart. Salah nyetel request nduwé ongkos nyata ing loro-loroné sisi: kacilikan lan node dadi overcommitted dadi Pod padha kaliren; kagedhèn lan kapasitas kebuwang déné Pod lungguh Pending amarga ora ana sing pas. Telu **kelas QoS** — Guaranteed (request padha karo limit), Burstable (request ngisor limit), lan BestEffort (ora disetel) — nemtokaké urutan eviction ing tekanan memory, kanthi BestEffort dipatèni dhisik lan Guaranteed pungkasan, pas karo apa sing sampeyan kudu ngerti kanggo nglindhungi workload kritis. Ngerti tuntunan praktis (setel memory request padha karo limit kanggo app kritis, right-size saka panganggoan nyata liwat `kubectl top`, meksa default nganggo LimitRange/ResourceQuota) ngowahi iki saka téori dadi perencanaan kapasitas sing waras. Amarga salah konfigurasi resource iku salah siji panyebab paling umum instabilitas, wragad kebuwang, lan Pod Pending ing cluster nyata, nguwasani request, limit, lan QoS iku dhasar kanggo njalanaké workload Kubernetes sing efisien lan stabil.

Request vs limit

Kepiyé scheduling nganggo request

Kelas QoS (nemtokaké urutan eviction ing tekanan memory)

Tuntunan praktis

Kenapa iki penting

Pitakon sing gegandhengan