Apakah perbezaan antara CPU/memory requests dan limits, dan bagaimana ia mempengaruhi scheduling, eviction, dan QoS?

Question

IT Interview Practice · Accepted Answer

**Requests** ialah apa yang *dijamin* untuk sebuah kontena (digunakan untuk scheduling); **limits** ialah *siling* yang tidak boleh dilebihinya (dikuatkuasakan pada masa runtime). Bersama-sama ia memacu di mana Pod diletakkan, bagaimana ia diperlahankan (throttle) atau dibunuh di bawah tekanan, dan kelas **Quality of Service (QoS)** mana yang diperoleh sebuah Pod.

## Requests berbanding limits

```text
REQUEST → jumlah yang DIRIZAB untuk kontena. SCHEDULER menggunakan jumlah request
          untuk memutuskan sama ada satu node ada ruang. Ini lantai jaminan anda.
LIMIT   → jumlah MAKS kontena boleh guna. Dikuatkuasakan pada masa runtime:
          CPU melebihi limit    → DI-THROTTLE (diperlahankan, tidak dibunuh)
          memory melebihi limit → OOM-KILLED (kontena ditamatkan, kemudian di-restart)
```

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

## Bagaimana scheduling menggunakan requests

```text
Node ada 4 CPU / 8Gi boleh diperuntukkan.
Scheduler menjumlahkan REQUEST Pod yang telah diletakkan; satu Pod baharu muat hanya jika
request-nya masih muat dalam baki. (Limit TIDAK digunakan untuk penempatan.)
→ Set request terlalu rendah → node terlebih komit, Pod berebut sumber.
→ Set request terlalu tinggi → kapasiti terbazir, Pod tersekat Pending (tiada yang muat).
```

## Kelas QoS (memutuskan susunan eviction di bawah tekanan memory)

```text
Guaranteed  → requests == limits untuk KEDUA-DUA cpu & memory (setiap kontena)
              → terakhir untuk di-evict (keutamaan tertinggi)
Burstable   → ada requests tetapi kurang daripada limits (atau ditetapkan separa)
              → di-evict selepas BestEffort
BestEffort  → tiada requests atau limits langsung
              → PERTAMA untuk di-evict apabila node kehabisan memory
```

```bash
kubectl describe pod app | grep -i qos    # QoS Class: Guaranteed/Burstable/BestEffort
kubectl top pods                           # penggunaan CPU/memory sebenar
kubectl describe node <node>               # sumber diperuntukkan berbanding kapasiti
```

## Panduan praktikal

```text
✓ Sentiasa set memory requests = limits untuk kelakuan boleh diramal, selamat-OOM pada app kritikal
✓ Set CPU requests kepada keperluan mantap; CPU limits selalu ditinggalkan untuk benarkan bursting
✓ Saiz-tepat daripada penggunaan sebenar (kubectl top / metrics) — bukan tekaan
✓ Guna LimitRange / ResourceQuota untuk kuatkuasakan default munasabah setiap namespace
```

## Mengapa ia penting

Requests dan limits ialah cara Kubernetes berkongsi sumber node yang terhad secara adil dan boleh diramal, jadi memahami perbezaan dan akibatnya ialah pengetahuan prestasi dan kebolehpercayaan yang penting. Pandangan teras ialah ia berkhidmat untuk tujuan berbeza: **requests** ialah rizab jaminan yang **scheduler** gunakan untuk meletakkan Pod (menjumlahkan request untuk memutuskan sama ada satu node ada ruang, mengabaikan limits), manakala **limits** ialah siling runtime yang dikuatkuasakan berbeza mengikut sumber — melebihi limit **CPU** menyebabkan anda di-**throttle** (diperlahankan), tetapi melebihi limit **memory** menyebabkan kontena **OOM-killed** dan di-restart. Menetapkan request salah ada kos sebenar pada kedua-dua belah: terlalu rendah dan node menjadi terlebih komit jadi Pod membiarkan satu sama lain kebuluran; terlalu tinggi dan kapasiti terbazir sementara Pod duduk Pending kerana tiada yang muat. Ketiga-tiga kelas **QoS** — Guaranteed (requests sama dengan limits), Burstable (requests di bawah limits), dan BestEffort (tiada ditetapkan) — menentukan susunan eviction di bawah tekanan memory, dengan BestEffort dibunuh dahulu dan Guaranteed terakhir, tepat apa yang anda perlu fahami untuk melindungi workload kritikal. Mengetahui panduan praktikal (set memory requests sama dengan limits untuk app kritikal, saiz-tepat daripada penggunaan sebenar melalui `kubectl top`, kuatkuasakan default dengan LimitRange/ResourceQuota) menukar ini daripada teori kepada perancangan kapasiti yang kukuh. Kerana salah konfigurasi sumber ialah salah satu punca paling biasa ketidakstabilan, perbelanjaan terbazir, dan Pod Pending dalam cluster sebenar, menguasai requests, limits, dan QoS adalah asas untuk menjalankan workload Kubernetes yang cekap dan stabil.

Requests berbanding limits

Bagaimana scheduling menggunakan requests

Kelas QoS (memutuskan susunan eviction di bawah tekanan memory)

Panduan praktikal

Mengapa ia penting

Soalan berkaitan