Menene bambanci tsakanin CPU/memory requests da limits, kuma yaya suke shafar scheduling, eviction, da QoS?

Question

IT Interview Practice · Accepted Answer

**Requests** su ne abin da container ke *tabbatar da* (ana amfani da su don scheduling); **limits** su ne *rufin* da ba zai iya wuce ba (ana tilastawa lokacin gudanarwa). Tare suna tuƙa inda ake sanya Pod, yadda ake dakushe su ko kashe su ƙarƙashin matsi, da wace **Quality of Service (QoS)** class Pod ke samu.

## Requests da limits

```text
REQUEST → adadin da aka AJIYE ga container. SCHEDULER yana amfani da jimlar
          requests don yanke ko node yana da wuri. Wannan shine ƙasan tabbatarwarka.
LIMIT   → MAFI YAWA da container zai iya amfani. Ana tilastawa lokacin gudanarwa:
          CPU sama da limit    → DAKUSHE (a rage saurin, ba a kashe ba)
          memory sama da limit → OOM-KILLED (an dakatar da container, sannan a sake kunnawa)
```

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      resources:
        requests:
          cpu: "250m"        # 0.25 na core, an tabbatar
          memory: "256Mi"
        limits:
          cpu: "500m"        # zai iya haura zuwa 0.5 core, sannan a dakushe
          memory: "512Mi"    # wuce wannan → OOMKilled
```

## Yadda scheduling ke amfani da requests

```text
Node yana da CPU 4 / 8Gi da za a iya rabawa.
Scheduler yana jimla REQUESTS na Pod da aka riga aka sanya; sabon Pod ya dace kawai idan
requests nasa har yanzu sun dace cikin abin da ya rage. (Ba a amfani da limits don sanyawa.)
→ Saita requests ƙasa da yawa → node overcommitted, Pod suna faɗa a kan albarkatu.
→ Saita requests sama da yawa → ɓata ƙarfi, Pod suna makale a Pending (babu abin da ya dace).
```

## QoS classes (yana yanke tsarin eviction ƙarƙashin matsin memory)

```text
Guaranteed  → requests == limits ga DUKA cpu & memory (kowane container)
              → na ƙarshe da za a evict (mafi fifiko)
Burstable   → yana da requests amma sun < limits (ko an saita wani ɓangare)
              → an evict bayan BestEffort
BestEffort  → babu requests ko limits kwata-kwata
              → NA FARKO da za a evict lokacin da node ya ƙarancin memory
```

```bash
kubectl describe pod app | grep -i qos    # QoS Class: Guaranteed/Burstable/BestEffort
kubectl top pods                           # ainihin amfani da CPU/memory
kubectl describe node <node>               # albarkatun da aka rabu da ƙarfi
```

## Jagora mai amfani

```text
✓ Kullum saita memory requests = limits don hali mai hasashe, mai OOM-safe a app masu muhimmanci
✓ Saita CPU requests zuwa buƙatar tsayayye; galibi ana barin CPU limits don ba da damar haurawa
✓ Girman daidai daga ainihin amfani (kubectl top / metrics) — ba zato ba
✓ Yi amfani da LimitRange / ResourceQuota don tilasta tsofaffi masu ma'ana ga kowane namespace
```

## Me ya sa yake da muhimmanci

Requests da limits su ne yadda Kubernetes ke raba albarkatun node masu iyaka cikin adalci da hasashe, don haka fahimtar bambanci da sakamakonsa ilimi ne mai mahimmanci na aiki da aminci. Ainihin fahimta shine cewa suna hidima manufofi daban: **requests** ajiya ce da aka tabbatar da **scheduler** ke amfani da ita don sanya Pod (yana jimlar requests don yanke ko node yana da wuri, yana kula da limits ba), yayin da **limits** rufi ne na lokacin gudanarwa da ake tilastawa daban ga kowace albarka — wuce limit na **CPU** yana ba ka **dakushewa** (rage sauri), amma wuce limit na **memory** yana sa a **OOM-kill** container a kuma sake kunna shi. Samun requests ba daidai ba yana da ainihin farashi a bangarorin biyu: ƙasa da yawa kuma nodes suna zama overcommitted don haka Pod suna yunwatar da juna; sama da yawa kuma ƙarfi ya ɓace yayin da Pod suke zaune a Pending saboda babu abin da ya dace. Nau'ikan **QoS** guda uku — Guaranteed (requests daidai da limits), Burstable (requests ƙasa da limits), da BestEffort (babu abin da aka saita) — suna yanke tsarin eviction ƙarƙashin matsin memory, da BestEffort da aka kashe da farko da Guaranteed na ƙarshe, wanda shine ainihin abin da kake buƙatar fahimta don kare workload masu muhimmanci. Sanin jagora mai amfani (saita memory requests daidai da limits ga app masu muhimmanci, girman daidai daga ainihin amfani ta `kubectl top`, tilasta tsofaffi da LimitRange/ResourceQuota) yana mai da wannan daga ka'ida zuwa kyakkyawan tsara ƙarfi. Saboda saita albarkatu ba daidai ba yana ɗaya daga cikin dalilan da suka fi yawaita na rashin kwanciyar hankali, kashe kuɗi mara amfani, da Pod na Pending a ainihin clusters, ƙware requests, limits, da QoS na tushe ne don gudanar da workload na Kubernetes masu inganci da kwanciyar hankali.

Requests da limits

Yadda scheduling ke amfani da requests

QoS classes (yana yanke tsarin eviction ƙarƙashin matsin memory)

Jagora mai amfani

Me ya sa yake da muhimmanci

Tambayoyi masu alaƙa