Ποια η διαφορά μεταξύ CPU/memory requests και limits, και πώς επηρεάζουν το scheduling, το eviction και το QoS;

Question

IT Interview Practice · Accepted Answer

Τα **requests** είναι αυτό που ένα container *εγγυημένα* παίρνει (χρησιμοποιείται για scheduling)· τα **limits** είναι το *ταβάνι* που δεν επιτρέπεται να ξεπεράσει (επιβάλλεται στο runtime). Μαζί καθορίζουν πού τοποθετούνται τα Pods, πώς περιορίζονται (throttle) ή σκοτώνονται υπό πίεση, και ποια κλάση **Quality of Service (QoS)** παίρνει ένα Pod.

## 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 ενός core, εγγυημένα
          memory: "256Mi"
        limits:
          cpu: "500m"        # μπορεί να ανέβει έως 0.5 core, μετά throttled
          memory: "512Mi"    # ξεπερνώντας το → 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 (καθορίζουν τη σειρά 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                           # πραγματική χρήση CPU/memory
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 μοιράζει τους πεπερασμένους πόρους των nodes δίκαια και προβλέψιμα, οπότε η κατανόηση της διάκρισης και των συνεπειών της είναι απαραίτητη γνώση απόδοσης και αξιοπιστίας. Η βασική διαπίστωση είναι ότι εξυπηρετούν διαφορετικούς σκοπούς: τα **requests** είναι μια εγγυημένη δέσμευση που ο **scheduler** χρησιμοποιεί για να τοποθετεί Pods (αθροίζοντας τα requests για να αποφασίσει αν ένας node έχει χώρο, αγνοώντας τα limits), ενώ τα **limits** είναι ένα ταβάνι runtime που επιβάλλεται διαφορετικά ανά πόρο — ξεπερνώντας ένα limit **CPU** σε κάνει **throttle** (σε επιβραδύνει), αλλά ξεπερνώντας ένα limit **memory** το container **OOM-killed** και επανεκκινεί. Το να βάζεις λάθος requests έχει πραγματικό κόστος και προς τις δύο πλευρές: πολύ χαμηλά και οι nodes γίνονται overcommitted οπότε τα Pods πεινούν το ένα το άλλο· πολύ ψηλά και η χωρητικότητα σπαταλιέται ενώ τα Pods μένουν Pending επειδή τίποτα δεν χωράει. Οι τρεις κλάσεις **QoS** — Guaranteed (requests ίσα με limits), Burstable (requests κάτω από limits), και BestEffort (τίποτα ορισμένο) — καθορίζουν τη σειρά eviction υπό πίεση μνήμης, με το BestEffort να σκοτώνεται πρώτο και το Guaranteed τελευταίο, ακριβώς αυτό που πρέπει να κατανοήσεις για να προστατεύσεις κρίσιμα workloads. Το να ξέρεις την πρακτική καθοδήγηση (βάλε memory requests ίσα με limits για κρίσιμες εφαρμογές, κάνε right-size από πραγματική χρήση μέσω `kubectl top`, επίβαλε defaults με LimitRange/ResourceQuota) το μετατρέπει από θεωρία σε στέρεο σχεδιασμό χωρητικότητας. Επειδή η κακή ρύθμιση πόρων είναι μία από τις πιο συχνές αιτίες αστάθειας, σπαταλημένου κόστους και Pending Pods σε πραγματικά clusters, η κατάκτηση των requests, των limits και του QoS είναι θεμελιώδης για να τρέχεις αποδοτικά, σταθερά workloads στο Kubernetes.

Requests vs limits

Πώς το scheduling χρησιμοποιεί τα requests

Κλάσεις QoS (καθορίζουν τη σειρά eviction υπό πίεση μνήμης)

Πρακτική καθοδήγηση

Γιατί έχει σημασία

Σχετικές ερωτήσεις