Kuna tofauti gani kati ya CPU/memory requests na limits, na huathiri vipi scheduling, eviction, na QoS?

Question

IT Interview Practice · Accepted Answer

**Requests** ni kile container inacho*hakikishiwa* (hutumika kwa scheduling); **limits** ni *dari* ambalo haiwezi kuvuka (hutekelezwa wakati wa runtime). Kwa pamoja huendesha mahali Pods huwekwa, jinsi zinavyodhibitiwa au kuuawa chini ya shinikizo, na darasa gani la **Quality of Service (QoS)** Pod hupata.

## Requests dhidi ya limits

```text
REQUEST → kiasi kilichoHIFADHIWA kwa container. SCHEDULER hutumia jumla ya
          requests kuamua kama node ina nafasi. Hii ni sakafu yako iliyohakikishwa.
LIMIT   → KIWANGO cha juu container inachoweza kutumia. Hutekelezwa wakati wa runtime:
          CPU juu ya limit    → HUDHIBITIWA (hupunguzwa kasi, haiuawi)
          memory juu ya limit → OOM-KILLED (container huzimwa, kisha huanzishwa upya)
```

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      resources:
        requests:
          cpu: "250m"        # 0.25 ya core, imehakikishwa
          memory: "256Mi"
        limits:
          cpu: "500m"        # inaweza ku-burst hadi 0.5 core, kisha hudhibitiwa
          memory: "512Mi"    # ukivuka hii → OOMKilled
```

## Jinsi scheduling inavyotumia requests

```text
Node ina 4 CPU / 8Gi allocatable.
Scheduler hujumlisha REQUESTS za Pods zilizowekwa tayari; Pod mpya hutoshea tu ikiwa
requests zake bado zinatoshea katika kilichobaki. (Limits HAZITUMIKI kwa uwekaji.)
→ Weka requests chini sana → node overcommitted, Pods hupigania rasilimali.
→ Weka requests juu sana → uwezo umepotea, Pods hukwama Pending (hakuna kinachotoshea).
```

## Madarasa ya QoS (huamua mpangilio wa eviction chini ya shinikizo la memory)

```text
Guaranteed  → requests == limits kwa VYOTE cpu na memory (kila container)
              → wa mwisho kutupwa (kipaumbele cha juu zaidi)
Burstable   → ina requests lakini ni < limits (au imewekwa kwa sehemu)
              → hutupwa baada ya BestEffort
BestEffort  → hakuna requests wala limits kabisa
              → wa KWANZA kutupwa wakati node inapopungukiwa memory
```

```bash
kubectl describe pod app | grep -i qos    # QoS Class: Guaranteed/Burstable/BestEffort
kubectl top pods                           # matumizi halisi ya CPU/memory
kubectl describe node <node>               # rasilimali zilizotengwa dhidi ya uwezo
```

## Mwongozo wa kivitendo

```text
✓ Daima weka memory requests = limits kwa tabia inayotabirika, salama-OOM kwenye apps muhimu
✓ Weka CPU requests kwa hitaji la steady-state; CPU limits mara nyingi huachwa kuruhusu bursting
✓ Pima ukubwa sahihi kutoka matumizi halisi (kubectl top / metrics) — si kubahatisha
✓ Tumia LimitRange / ResourceQuota kutekeleza chaguo-msingi zenye maana kwa kila namespace
```

## Kwa nini ni muhimu

Requests na limits ndiyo jinsi Kubernetes inavyoshiriki rasilimali finyu za node kwa haki na kutabirika, hivyo kuelewa tofauti na matokeo yake ni maarifa muhimu ya utendaji na uaminifu. Ufahamu wa msingi ni kwamba huhudumia madhumuni tofauti: **requests** ni hifadhi iliyohakikishwa ambayo **scheduler** hutumia kuweka Pods (kujumlisha requests kuamua kama node ina nafasi, kupuuza limits), wakati **limits** ni dari la runtime linalotekelezwa tofauti kwa kila rasilimali — kuvuka limit ya **CPU** hukudhibitisha (hupunguza kasi), lakini kuvuka limit ya **memory** hufanya container **OOM-killed** na kuanzishwa upya. Kupata requests vibaya kuna gharama halisi pande zote mbili: chini sana na nodes huwa overcommitted hivyo Pods hunyimana; juu sana na uwezo hupotea wakati Pods zinakaa Pending kwa sababu hakuna kinachotoshea. Madarasa matatu ya **QoS** — Guaranteed (requests sawa na limits), Burstable (requests chini ya limits), na BestEffort (hakuna kilichowekwa) — huamua mpangilio wa eviction chini ya shinikizo la memory, ambapo BestEffort huuawa kwanza na Guaranteed mwisho, ambacho ndicho hasa unachohitaji kuelewa ili kulinda workloads muhimu. Kujua mwongozo wa kivitendo (weka memory requests sawa na limits kwa apps muhimu, pima ukubwa sahihi kutoka matumizi halisi kupitia `kubectl top`, tekeleza chaguo-msingi kwa LimitRange/ResourceQuota) hugeuza hii kutoka nadharia kuwa mipango imara ya uwezo. Kwa kuwa usanidi mbaya wa rasilimali ni moja ya sababu za kawaida za kutokuwa imara, matumizi ya pesa yaliyopotea, na Pods za Pending kwenye clusters halisi, kumudu requests, limits, na QoS ni msingi wa kuendesha workloads bora na thabiti za Kubernetes.

Requests dhidi ya limits

Jinsi scheduling inavyotumia requests

Madarasa ya QoS (huamua mpangilio wa eviction chini ya shinikizo la memory)

Mwongozo wa kivitendo

Kwa nini ni muhimu

Maswali yanayohusiana