Cili është ndryshimi midis CPU/memory requests dhe limits, dhe si ndikojnë te scheduling, eviction dhe QoS?

Question

IT Interview Practice · Accepted Answer

**Requests** janë ato që një container ka *të garantuara* (përdoret për scheduling); **limits** janë *tavani* që nuk mund ta kalojë (i zbatuar në runtime). Së bashku ato përcaktojnë ku vendosen Pod-et, si throttle-ohen ose vriten nën presion, dhe cilën klasë **Quality of Service (QoS)** merr një Pod.

## Requests vs limits

```text
REQUEST → sasia E REZERVUAR për container-in. SCHEDULER-i përdor shumën e
          request-eve për të vendosur nëse një node ka vend. Ky është dyshemeja jote e garantuar.
LIMIT   → MAKSIMUMI që container-i mund të përdorë. I zbatuar në runtime:
          CPU mbi limit    → THROTTLE (ngadalësohet, jo i vrarë)
          memory mbi limit → OOM-KILL (container-i përfundon, pastaj riniset)
```

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      resources:
        requests:
          cpu: "250m"        # 0.25 e një core, i garantuar
          memory: "256Mi"
        limits:
          cpu: "500m"        # mund të bëjë burst deri në 0.5 core, pastaj throttle
          memory: "512Mi"    # kalo këtë → OOMKilled
```

## Si e përdor scheduling-u request-et

```text
Node ka 4 CPU / 8Gi të alokueshme.
Scheduler-i mbledh REQUEST-et e Pod-eve tashmë të vendosur; një Pod i ri hyn vetëm nëse
request-et e tij ende hyjnë në atë që mbetet. (Limits NUK përdoren për vendosje.)
→ Vendos request-e shumë të ulëta → node i overcommited, Pod-et luftojnë për resource.
→ Vendos request-e shumë të larta → kapacitet i harxhuar, Pod-e të ngecur Pending (asgjë nuk hyn).
```

## Klasat QoS (vendos renditjen e eviction-it nën presion memory-je)

```text
Guaranteed  → requests == limits për TË DYJA cpu & memory (çdo container)
              → i fundit që bëhet evict (prioriteti më i lartë)
Burstable   → ka requests por janë < limits (ose të vendosura pjesërisht)
              → bëhet evict pas BestEffort
BestEffort  → asnjë requests apo limits fare
              → I PARI që bëhet evict kur node-i mbetet pa memory
```

```bash
kubectl describe pod app | grep -i qos    # QoS Class: Guaranteed/Burstable/BestEffort
kubectl top pods                           # përdorimi faktik i CPU/memory
kubectl describe node <node>               # resource-t e alokuar vs kapaciteti
```

## Udhëzim praktik

```text
✓ Gjithmonë vendos memory requests = limits për sjellje të parashikueshme, të sigurt-ndaj-OOM te app kritikë
✓ Vendos CPU requests te nevoja e qëndrueshme; CPU limits shpesh lihen bosh për të lejuar burst
✓ Përcakto madhësinë e duhur nga përdorimi real (kubectl top / metrics) — jo hamendje
✓ Përdor LimitRange / ResourceQuota për të zbatuar default të arsyeshëm për çdo namespace
```

## Pse ka rëndësi

Requests dhe limits janë mënyra si Kubernetes ndan resource-t e fundme të node-eve në mënyrë të drejtë dhe të parashikueshme, kështu që të kuptosh dallimin dhe pasojat e tij është njohuri thelbësore performance dhe besueshmërie. Njohuria thelbësore është që ata shërbejnë qëllime të ndryshme: **requests** janë një rezervim i garantuar që **scheduler**-i përdor për të vendosur Pod-et (duke mbledhur request-et për të vendosur nëse një node ka vend, duke injoruar limits), ndërsa **limits** janë një tavan runtime i zbatuar ndryshe për çdo resource — kalimi i një limit-i **CPU** të bën **throttle** (ngadalësohesh), por kalimi i një limit-i **memory** e bën container-in **OOM-kill** dhe restart. Vendosja gabim e request-eve ka kosto reale në të dyja anët: shumë të ulëta dhe node-et bëhen të overcommited kështu që Pod-et e urin njëri-tjetrin; shumë të larta dhe kapaciteti harxhohet ndërsa Pod-et rrinë Pending sepse asgjë nuk hyn. Tre klasat **QoS** — Guaranteed (requests baraz me limits), Burstable (requests nën limits), dhe BestEffort (asgjë e vendosur) — përcaktojnë renditjen e eviction-it nën presion memory-je, me BestEffort të vrarë i pari dhe Guaranteed i fundit, që është pikërisht ajo që të duhet të kuptosh për të mbrojtur workload-e kritike. Të dish udhëzimin praktik (vendos memory requests baraz me limits për app kritikë, përcakto madhësinë e duhur nga përdorimi real nëpërmjet `kubectl top`, zbato default me LimitRange/ResourceQuota) e kthen këtë nga teori në planifikim solid kapaciteti. Meqë keqkonfigurimi i resource-ve është një nga shkaqet më të zakonshme të paqëndrueshmërisë, shpenzimit të harxhuar dhe Pod-eve Pending në cluster-a realë, zotërimi i requests, limits dhe QoS është themelor për të drejtuar workload-e Kubernetes efikas dhe të qëndrueshëm.

Requests vs limits

Si e përdor scheduling-u request-et

Klasat QoS (vendos renditjen e eviction-it nën presion memory-je)

Udhëzim praktik

Pse ka rëndësi

Pyetje të ngjashme