CPU/memory requests ਅਤੇ limits ਵਿੱਚ ਕੀ ਫ਼ਰਕ ਹੈ, ਅਤੇ ਇਹ scheduling, eviction, ਤੇ QoS ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ?

Question

IT Interview Practice · Accepted Answer

**Requests** ਉਹ ਹਨ ਜੋ ਇੱਕ container ਨੂੰ *ਗਾਰੰਟੀਸ਼ੁਦਾ* ਮਿਲਦਾ ਹੈ (scheduling ਲਈ ਵਰਤਿਆ); **limits** ਉਹ *ਛੱਤ* ਹਨ ਜਿਸ ਤੋਂ ਇਹ ਵੱਧ ਨਹੀਂ ਹੋ ਸਕਦਾ (runtime 'ਤੇ ਲਾਗੂ)। ਮਿਲ ਕੇ ਇਹ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ Pod ਕਿੱਥੇ ਰੱਖੇ ਜਾਂਦੇ ਹਨ, ਦਬਾਅ ਹੇਠ ਉਹ ਕਿਵੇਂ throttle ਜਾਂ ਮਾਰੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਇੱਕ Pod ਨੂੰ ਕਿਹੜੀ **Quality of Service (QoS)** class ਮਿਲਦੀ ਹੈ।

## Requests ਬਨਾਮ limits

```text
REQUEST → container ਲਈ RESERVED ਮਾਤਰਾ। SCHEDULER request ਦੇ ਜੋੜ ਦੀ ਵਰਤੋਂ ਇਹ ਤੈਅ ਕਰਨ ਲਈ
          ਕਰਦਾ ਹੈ ਕਿ ਕਿਸੇ node ਕੋਲ ਜਗ੍ਹਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਇਹ ਤੁਹਾਡਾ ਗਾਰੰਟੀਸ਼ੁਦਾ ਫ਼ਰਸ਼ ਹੈ।
LIMIT   → container ਵੱਧ ਤੋਂ ਵੱਧ ਜੋ ਵਰਤ ਸਕਦਾ ਹੈ। runtime 'ਤੇ ਲਾਗੂ:
          CPU over limit    → THROTTLED (ਹੌਲੀ ਕੀਤਾ, ਮਾਰਿਆ ਨਹੀਂ)
          memory over limit → OOM-KILLED (container ਖ਼ਤਮ, ਫਿਰ restart)
```

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      resources:
        requests:
          cpu: "250m"        # ਇੱਕ core ਦਾ 0.25, ਗਾਰੰਟੀਸ਼ੁਦਾ
          memory: "256Mi"
        limits:
          cpu: "500m"        # 0.5 core ਤੱਕ burst ਹੋ ਸਕਦਾ, ਫਿਰ throttle
          memory: "512Mi"    # ਇਸ ਤੋਂ ਵੱਧ → OOMKilled
```

## Scheduling requests ਕਿਵੇਂ ਵਰਤਦਾ ਹੈ

```text
Node ਕੋਲ 4 CPU / 8Gi allocatable ਹੈ।
Scheduler ਪਹਿਲਾਂ ਹੀ ਰੱਖੇ Pod ਦੇ REQUESTS ਜੋੜਦਾ ਹੈ; ਇੱਕ ਨਵਾਂ Pod ਤਾਂ ਹੀ fit ਹੁੰਦਾ ਹੈ ਜੇ ਇਸਦੇ
request ਬਾਕੀ ਬਚੀ ਜਗ੍ਹਾ ਵਿੱਚ ਹਾਲੇ ਵੀ fit ਹੋਣ। (Limits placement ਲਈ ਨਹੀਂ ਵਰਤੇ ਜਾਂਦੇ।)
→ request ਬਹੁਤ ਘੱਟ ਸੈੱਟ ਕਰੋ → node overcommit, Pod resource ਲਈ ਲੜਦੇ ਹਨ।
→ request ਬਹੁਤ ਵੱਧ ਸੈੱਟ ਕਰੋ → ਬਰਬਾਦ ਸਮਰੱਥਾ, Pod Pending 'ਤੇ ਫਸੇ (ਕੁਝ fit ਨਹੀਂ ਹੁੰਦਾ)।
```

## QoS classes (memory ਦਬਾਅ ਹੇਠ eviction ਦਾ ਕ੍ਰਮ ਤੈਅ ਕਰਦੇ ਹਨ)

```text
Guaranteed  → cpu ਤੇ memory ਦੋਵਾਂ ਲਈ requests == limits (ਹਰ container)
              → ਸਭ ਤੋਂ ਅਖ਼ੀਰ evict (ਸਭ ਤੋਂ ਵੱਧ ਤਰਜੀਹ)
Burstable   → requests ਹਨ ਪਰ ਉਹ < limits (ਜਾਂ ਅੰਸ਼ਿਕ ਤੌਰ 'ਤੇ ਸੈੱਟ)
              → BestEffort ਤੋਂ ਬਾਅਦ evict
BestEffort  → ਕੋਈ requests ਜਾਂ limits ਬਿਲਕੁਲ ਨਹੀਂ
              → ਜਦੋਂ node memory ਵਿੱਚ ਘੱਟ ਪੈਂਦਾ ਹੈ ਤਾਂ ਸਭ ਤੋਂ ਪਹਿਲਾਂ evict
```

```bash
kubectl describe pod app | grep -i qos    # QoS Class: Guaranteed/Burstable/BestEffort
kubectl top pods                           # ਅਸਲ CPU/memory ਵਰਤੋਂ
kubectl describe node <node>               # allocated resources ਬਨਾਮ capacity
```

## ਵਿਹਾਰਕ ਮਾਰਗਦਰਸ਼ਨ

```text
✓ ਮਹੱਤਵਪੂਰਨ ਐਪਸ 'ਤੇ ਅਨੁਮਾਨਯੋਗ, OOM-ਸੁਰੱਖਿਅਤ ਵਿਵਹਾਰ ਲਈ ਹਮੇਸ਼ਾ memory requests = limits ਸੈੱਟ ਕਰੋ
✓ CPU requests ਨੂੰ steady-state ਲੋੜ 'ਤੇ ਸੈੱਟ ਕਰੋ; bursting ਦੀ ਆਗਿਆ ਲਈ CPU limits ਅਕਸਰ ਛੱਡ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ
✓ ਅਸਲ ਵਰਤੋਂ ਤੋਂ ਸਹੀ-ਆਕਾਰ ਕਰੋ (kubectl top / metrics) — ਅੰਦਾਜ਼ੇ ਨਹੀਂ
✓ ਹਰ namespace ਲਈ ਸਮਝਦਾਰ default ਲਾਗੂ ਕਰਨ ਲਈ LimitRange / ResourceQuota ਵਰਤੋ
```

## ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

Requests ਅਤੇ limits ਹੀ ਉਹ ਤਰੀਕਾ ਹਨ ਜਿਸ ਨਾਲ Kubernetes ਸੀਮਿਤ node resources ਨੂੰ ਨਿਰਪੱਖ ਅਤੇ ਅਨੁਮਾਨਯੋਗ ਢੰਗ ਨਾਲ ਸਾਂਝਾ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਫ਼ਰਕ ਅਤੇ ਇਸਦੇ ਨਤੀਜਿਆਂ ਨੂੰ ਸਮਝਣਾ ਜ਼ਰੂਰੀ performance ਅਤੇ reliability ਗਿਆਨ ਹੈ। ਮੁੱਖ ਸੂਝ ਇਹ ਹੈ ਕਿ ਇਹ ਵੱਖਰੇ ਮਕਸਦ ਪੂਰੇ ਕਰਦੇ ਹਨ: **requests** ਇੱਕ ਗਾਰੰਟੀਸ਼ੁਦਾ reservation ਹਨ ਜੋ **scheduler** Pod ਰੱਖਣ ਲਈ ਵਰਤਦਾ ਹੈ (node ਕੋਲ ਜਗ੍ਹਾ ਹੈ ਜਾਂ ਨਹੀਂ ਇਹ ਤੈਅ ਕਰਨ ਲਈ requests ਜੋੜਦਾ, limits ਅਣਗੌਲੇ ਕਰਦਾ), ਜਦੋਂ ਕਿ **limits** ਇੱਕ runtime ਛੱਤ ਹਨ ਜੋ ਹਰ resource ਲਈ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਲਾਗੂ ਹੁੰਦੀ ਹੈ — ਇੱਕ **CPU** limit ਤੋਂ ਵੱਧ ਹੋਣ 'ਤੇ ਤੁਸੀਂ **throttled** (ਹੌਲੀ) ਹੋ ਜਾਂਦੇ ਹੋ, ਪਰ ਇੱਕ **memory** limit ਤੋਂ ਵੱਧ ਹੋਣ 'ਤੇ container **OOM-killed** ਹੋ ਕੇ restart ਹੁੰਦਾ ਹੈ। requests ਨੂੰ ਗ਼ਲਤ ਕਰਨ ਦੀ ਦੋਵਾਂ ਪਾਸਿਓਂ ਅਸਲ ਕੀਮਤ ਹੈ: ਬਹੁਤ ਘੱਟ ਤਾਂ node overcommit ਹੋ ਜਾਂਦੇ ਹਨ ਇਸ ਲਈ Pod ਇੱਕ-ਦੂਜੇ ਨੂੰ ਭੁੱਖੇ ਮਾਰਦੇ ਹਨ; ਬਹੁਤ ਵੱਧ ਤਾਂ ਸਮਰੱਥਾ ਬਰਬਾਦ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਕਿ Pod Pending ਬੈਠੇ ਰਹਿੰਦੇ ਹਨ ਕਿਉਂਕਿ ਕੁਝ fit ਨਹੀਂ ਹੁੰਦਾ। ਤਿੰਨ **QoS classes** — Guaranteed (requests limits ਦੇ ਬਰਾਬਰ), Burstable (requests limits ਤੋਂ ਹੇਠਾਂ), ਅਤੇ BestEffort (ਕੁਝ ਸੈੱਟ ਨਹੀਂ) — memory ਦਬਾਅ ਹੇਠ eviction ਦਾ ਕ੍ਰਮ ਤੈਅ ਕਰਦੇ ਹਨ, BestEffort ਪਹਿਲਾਂ ਮਾਰਿਆ ਜਾਂਦਾ ਅਤੇ Guaranteed ਅਖ਼ੀਰ, ਜੋ ਠੀਕ ਉਹੀ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਮਹੱਤਵਪੂਰਨ workload ਦੀ ਰਾਖੀ ਲਈ ਸਮਝਣ ਦੀ ਲੋੜ ਹੈ। ਵਿਹਾਰਕ ਮਾਰਗਦਰਸ਼ਨ ਜਾਣਨਾ (ਮਹੱਤਵਪੂਰਨ ਐਪਸ ਲਈ memory requests ਨੂੰ limits ਦੇ ਬਰਾਬਰ ਸੈੱਟ ਕਰੋ, `kubectl top` ਰਾਹੀਂ ਅਸਲ ਵਰਤੋਂ ਤੋਂ ਸਹੀ-ਆਕਾਰ ਕਰੋ, LimitRange/ResourceQuota ਨਾਲ default ਲਾਗੂ ਕਰੋ) ਇਸਨੂੰ ਸਿਧਾਂਤ ਤੋਂ ਠੋਸ capacity planning ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਕਿਉਂਕਿ resource ਦੀ ਗ਼ਲਤ-ਸੰਰਚਨਾ ਅਸਲ cluster ਵਿੱਚ ਅਸਥਿਰਤਾ, ਬਰਬਾਦ ਖ਼ਰਚ, ਅਤੇ Pending Pod ਦੇ ਸਭ ਤੋਂ ਆਮ ਕਾਰਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ, requests, limits, ਅਤੇ QoS ਵਿੱਚ ਮੁਹਾਰਤ Kubernetes workload ਨੂੰ ਕੁਸ਼ਲ ਅਤੇ ਸਥਿਰ ਢੰਗ ਨਾਲ ਚਲਾਉਣ ਦੀ ਨੀਂਹ ਹੈ।

Requests ਬਨਾਮ limits

Scheduling requests ਕਿਵੇਂ ਵਰਤਦਾ ਹੈ

QoS classes (memory ਦਬਾਅ ਹੇਠ eviction ਦਾ ਕ੍ਰਮ ਤੈਅ ਕਰਦੇ ਹਨ)

ਵਿਹਾਰਕ ਮਾਰਗਦਰਸ਼ਨ

ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

ਸੰਬੰਧਿਤ ਸਵਾਲ