რა განსხვავებაა CPU/მეხსიერების request-ებსა და limit-ებს შორის და როგორ მოქმედებენ ისინი scheduling-ზე, eviction-სა და QoS-ზე?

Question

IT Interview Practice · Accepted Answer

**Request-ები** არის ის, რაც კონტეინერს *გარანტირებული* აქვს (გამოიყენება scheduling-ისთვის); **limit-ები** არის *ჭერი*, რომელსაც ის ვერ გადააჭარბებს (აღსრულდება runtime-ზე). ერთად ისინი განსაზღვრავენ, სად თავსდება Pod-ები, როგორ იზღუდება ან იკვლება ისინი წნეხის ქვეშ და რომელ **Quality of Service (QoS)** კლასს იღებს Pod.

## Request-ები vs limit-ები

```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 request-ებს

```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/მეხსიერების ფაქტობრივი გამოყენება
kubectl describe node <node>               # გამოყოფილი რესურსები vs სიმძლავრე
```

## პრაქტიკული რჩევა

```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
```

## რატომ არის ეს მნიშვნელოვანი

request-ები და limit-ები არის ის, თუ როგორ ანაწილებს Kubernetes node-ის სასრულ რესურსებს სამართლიანად და პროგნოზირებადად, ამიტომ განსხვავებისა და მისი შედეგების გაგება არსებითი წარმადობისა და საიმედოობის ცოდნაა. ძირითადი შეხედულება ისაა, რომ ისინი სხვადასხვა მიზანს ემსახურებიან: **request-ები** გარანტირებული რეზერვია, რომელსაც **scheduler** იყენებს Pod-ების განსათავსებლად (request-ების ჯამით წყვეტს, აქვს თუ არა node-ს ადგილი, limit-ების იგნორირებით), ხოლო **limit-ები** runtime-ის ჭერია, რომელიც სხვადასხვა რესურსზე სხვადასხვაგვარად აღსრულდება — **CPU** limit-ის გადაჭარბება იწვევს **throttling-ს** (შენელებას), ხოლო **მეხსიერების** limit-ის გადაჭარბება იწვევს კონტეინერის **OOM-kill-ს** და გადატვირთვას. request-ების არასწორად დაყენებას ორივე მხრიდან რეალური ღირებულება აქვს: ძალიან დაბალი და node-ები გადატვირთული ხდება, ასე რომ Pod-ები ერთმანეთს ამშივებენ; ძალიან მაღალი და სიმძლავრე იკარგება, ხოლო Pod-ები Pending-ში ისხდებიან, რადგან არაფერი ეტევა. სამი **QoS კლასი** — Guaranteed (request-ები limit-ების ტოლია), Burstable (request-ები limit-ებზე დაბალია) და BestEffort (არაფერია დაყენებული) — განსაზღვრავს eviction-ის რიგს მეხსიერების წნეხის ქვეშ, სადაც BestEffort პირველი იკვლება, ხოლო Guaranteed უკანასკნელი, რაც სწორედ ის არის, რაც უნდა გესმოდეთ კრიტიკული workload-ების დასაცავად. პრაქტიკული რჩევის ცოდნა (კრიტიკული აპლიკაციებისთვის მეხსიერების request-ები limit-ების ტოლი დააყენეთ, ზომა რეალური გამოყენებიდან `kubectl top`-ით შეარჩიეთ, ნაგულისხმევები LimitRange/ResourceQuota-ით აღასრულეთ) ამას თეორიიდან საღ სიმძლავრის დაგეგმვად აქცევს. რადგან რესურსების არასწორი კონფიგურაცია რეალურ კლასტერებში არასტაბილურობის, დახარჯული ხარჯისა და Pending Pod-ების ერთ-ერთი ყველაზე გავრცელებული მიზეზია, request-ების, limit-ებისა და QoS-ის დაუფლება ფუნდამენტურია Kubernetes-ის ეფექტიანი, სტაბილური workload-ების გასაშვებად.

Request-ები vs limit-ები

როგორ იყენებს scheduling request-ებს

QoS კლასები (განსაზღვრავს eviction-ის რიგს მეხსიერების წნეხის ქვეშ)

პრაქტიკული რჩევა

რატომ არის ეს მნიშვნელოვანი

დაკავშირებული კითხვები