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 vs limits

```text
REQUEST → the amount RESERVED for the container. The SCHEDULER uses the sum of
          requests to decide if a node has room. This is your guaranteed floor.
LIMIT   → the MAX the container may use. Enforced at runtime:
          CPU over limit    → THROTTLED (slowed down, not killed)
          memory over limit → OOM-KILLED (container terminated, then restarted)
```

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      resources:
        requests:
          cpu: "250m"        # 0.25 of a core, guaranteed
          memory: "256Mi"
        limits:
          cpu: "500m"        # may burst to 0.5 core, then throttled
          memory: "512Mi"    # exceed this → OOMKilled
```

## Scheduling requests ஐ எப்படிப் பயன்படுத்துகிறது

```text
Node has 4 CPU / 8Gi allocatable.
Scheduler sums the REQUESTS of Pods already placed; a new Pod fits only if its
requests still fit in what remains. (Limits are NOT used for placement.)
→ Set requests too low → node overcommitted, Pods fight for resources.
→ Set requests too high → wasted capacity, Pods stuck Pending (nothing fits).
```

## QoS class கள் (memory அழுத்தத்தின் கீழ் eviction வரிசையைத் தீர்மானிக்கிறது)

```text
Guaranteed  → requests == limits for BOTH cpu & memory (every container)
              → last to be evicted (highest priority)
Burstable   → has requests but they are < limits (or partially set)
              → evicted after BestEffort
BestEffort  → no requests or limits at all
              → FIRST to be evicted when the node runs low on memory
```

```bash
kubectl describe pod app | grep -i qos    # QoS Class: Guaranteed/Burstable/BestEffort
kubectl top pods                           # actual CPU/memory usage
kubectl describe node <node>               # Allocated resources vs capacity
```

## நடைமுறை வழிகாட்டல்

```text
✓ Always set memory requests = limits for predictable, OOM-safe behavior on critical apps
✓ Set CPU requests to the steady-state need; CPU limits are often left off to allow bursting
✓ Right-size from real usage (kubectl top / metrics) — not guesses
✓ Use LimitRange / ResourceQuota to enforce sane defaults per namespace
```

## இது ஏன் முக்கியம்

Requests மற்றும் limits தான் Kubernetes வரையறுக்கப்பட்ட node resource களை நியாயமாகவும் கணிக்கக்கூடியதாகவும் பகிர்ந்துகொள்ளும் விதம், எனவே வேறுபாட்டையும் அதன் விளைவுகளையும் புரிந்துகொள்வது அத்தியாவசியமான செயல்திறன் மற்றும் reliability அறிவு. மைய நுண்ணறிவு அவை வெவ்வேறு நோக்கங்களைச் செய்கின்றன என்பது: **requests** என்பது **scheduler** Pod களை வைக்கப் பயன்படுத்தும் ஒரு உத்தரவாதமான reservation (limit களைப் புறக்கணித்து, ஒரு node-க்கு இடம் உள்ளதா என்பதைத் தீர்மானிக்க request களைக் கூட்டுகிறது), அதேசமயம் **limits** என்பது ஒவ்வொரு resource-க்கும் வேறுவிதமாக அமல்படுத்தப்படும் ஒரு runtime உச்சவரம்பு — ஒரு **CPU** limit ஐத் தாண்டினால் நீங்கள் **throttle** செய்யப்படுகிறீர்கள் (மெதுவாக்கப்படுகிறீர்கள்), ஆனால் ஒரு **memory** limit ஐத் தாண்டினால் container **OOM-kill** செய்யப்பட்டு restart செய்யப்படுகிறது. Requests ஐ தவறாகப் பெறுவது இரு பக்கங்களிலும் நிஜமான செலவுகளைக் கொண்டுள்ளது: மிகக் குறைவாக இருந்தால் node கள் overcommit ஆகி Pod கள் ஒன்றையொன்று பட்டினி போடுகின்றன; மிக அதிகமாக இருந்தால் capacity வீணாகி Pod கள் எதுவும் பொருந்தாததால் Pending-இல் அமர்ந்திருக்கின்றன. மூன்று **QoS class கள்** — Guaranteed (requests limit களுக்குச் சமம்), Burstable (requests limit களுக்குக் கீழே), மற்றும் BestEffort (எதுவும் அமைக்கப்படவில்லை) — memory அழுத்தத்தின் கீழ் eviction வரிசையைத் தீர்மானிக்கின்றன, BestEffort முதலில் கொல்லப்படுகிறது, Guaranteed கடைசியாக, critical workload களைப் பாதுகாக்க நீங்கள் புரிந்துகொள்ள வேண்டியது சரியாக இதுதான். நடைமுறை வழிகாட்டலை அறிவது (critical app களுக்கு memory requests ஐ limit களுக்குச் சமமாக அமைப்பது, `kubectl top` வழியாக நிஜ usage-லிருந்து right-size செய்வது, LimitRange/ResourceQuota உடன் default களை அமல்படுத்துவது) இதைக் கோட்பாட்டிலிருந்து உறுதியான capacity planning ஆக மாற்றுகிறது. Resource misconfiguration நிஜமான cluster களில் instability, வீணான செலவு, மற்றும் Pending Pod களின் மிகப் பொதுவான காரணங்களில் ஒன்றாக இருப்பதால், requests, limits, மற்றும் QoS ஐ தேர்ச்சி பெறுவது திறமையான, நிலையான Kubernetes workload களை இயக்குவதற்கு அடிப்படையானது.

Requests vs limits

Scheduling requests ஐ எப்படிப் பயன்படுத்துகிறது

QoS class கள் (memory அழுத்தத்தின் கீழ் eviction வரிசையைத் தீர்மானிக்கிறது)

நடைமுறை வழிகாட்டல்

இது ஏன் முக்கியம்

தொடர்புடைய கேள்விகள்