CPU/bellek request'leri ile limit'leri arasındaki fark nedir ve bunlar scheduling'i, eviction'ı ve QoS'u nasıl etkiler?

Question

IT Interview Practice · Accepted Answer

**Request'ler**, bir container'a *garanti edilen* şeydir (scheduling için kullanılır); **limit'ler** ise aşamayacağı *tavandır* (runtime'da uygulanır). Birlikte, Pod'ların nereye yerleştirileceğini, baskı altında nasıl throttle edileceğini veya öldürüleceğini ve bir Pod'un hangi **Quality of Service (QoS)** sınıfını alacağını belirlerler.

## Request'ler ve limit'ler

```text
REQUEST → container için AYRILAN miktar. SCHEDULER, bir node'da yer olup olmadığına
          karar vermek için request'lerin toplamını kullanır. Bu, garanti edilen tabanınızdır.
LIMIT   → container'ın kullanabileceği MAKSİMUM. Runtime'da uygulanır:
          CPU limiti aşılırsa    → THROTTLE edilir (yavaşlatılır, öldürülmez)
          bellek limiti aşılırsa → OOM-KILL edilir (container sonlandırılır, sonra restart)
```

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      resources:
        requests:
          cpu: "250m"        # bir çekirdeğin 0.25'i, garanti
          memory: "256Mi"
        limits:
          cpu: "500m"        # 0.5 çekirdeğe kadar patlayabilir, sonra throttle
          memory: "512Mi"    # bunu aş → OOMKilled
```

## Scheduling request'leri nasıl kullanır

```text
Node'da 4 CPU / 8Gi tahsis edilebilir var.
Scheduler, halihazırda yerleştirilmiş Pod'ların REQUEST'lerini toplar; yeni bir Pod ancak
request'leri kalan kısma sığıyorsa yerleşir. (Limit'ler yerleştirmede KULLANILMAZ.)
→ Request'leri çok düşük ayarla → node overcommit olur, Pod'lar kaynak için kapışır.
→ Request'leri çok yüksek ayarla → kapasite israfı, Pod'lar Pending'de takılır (hiçbir şey sığmaz).
```

## QoS sınıfları (bellek baskısı altında eviction sırasını belirler)

```text
Guaranteed  → CPU & bellek İKİSİ için de request == limit (her container)
              → en son evict edilir (en yüksek öncelik)
Burstable   → request'leri var ama < limit (veya kısmen ayarlı)
              → BestEffort'tan sonra evict edilir
BestEffort  → hiç request veya limit yok
              → node bellek azaldığında İLK evict edilen
```

```bash
kubectl describe pod app | grep -i qos    # QoS Class: Guaranteed/Burstable/BestEffort
kubectl top pods                           # gerçek CPU/bellek kullanımı
kubectl describe node <node>               # Tahsis edilen kaynaklar ile kapasite
```

## Pratik rehberlik

```text
✓ Kritik app'lerde öngörülebilir, OOM-güvenli davranış için bellek request = limit ayarla
✓ CPU request'ini sürekli durum ihtiyacına ayarla; CPU limit'leri patlamaya izin için çoğu zaman boş bırakılır
✓ Gerçek kullanımdan doğru boyutlandır (kubectl top / metrics) — tahminle değil
✓ Namespace başına makul varsayılanları zorlamak için LimitRange / ResourceQuota kullan
```

## Neden önemli

Request'ler ve limit'ler, Kubernetes'in sınırlı node kaynaklarını adil ve öngörülebilir biçimde paylaştırma yoludur; bu yüzden ayrımı ve sonuçlarını anlamak elzem bir performans ve güvenilirlik bilgisidir. Çekirdek içgörü, farklı amaçlara hizmet ettikleridir: **request'ler**, **scheduler**'ın Pod'ları yerleştirmek için kullandığı garanti edilmiş bir rezervasyondur (bir node'da yer olup olmadığına karar vermek için request'leri toplar, limit'leri yok sayar), **limit'ler** ise kaynak başına farklı uygulanan bir runtime tavanıdır — bir **CPU** limitini aşmak sizi **throttle** ettirir (yavaşlatır), ancak bir **bellek** limitini aşmak container'ı **OOM-kill** ettirir ve restart eder. Request'leri yanlış ayarlamanın her iki tarafta da gerçek maliyeti vardır: çok düşük olursa node'lar overcommit olur ve Pod'lar birbirini aç bırakır; çok yüksek olursa hiçbir şey sığmadığı için Pod'lar Pending'de otururken kapasite israf olur. Üç **QoS sınıfı** — Guaranteed (request'ler limit'lere eşit), Burstable (request'ler limit'lerin altında) ve BestEffort (hiçbir şey ayarlı değil) — bellek baskısı altında eviction sırasını belirler; BestEffort ilk, Guaranteed son öldürülür ki bu tam olarak kritik workload'ları korumak için anlamanız gereken şeydir. Pratik rehberliği bilmek (kritik app'ler için bellek request'ini limit'e eşitle, `kubectl top` yoluyla gerçek kullanımdan doğru boyutlandır, LimitRange/ResourceQuota ile varsayılanları zorla) bunu teoriden sağlam kapasite planlamasına dönüştürür. Kaynak yanlış yapılandırması gerçek cluster'larda kararsızlığın, boşa harcamanın ve Pending Pod'ların en yaygın nedenlerinden biri olduğundan, request'lere, limit'lere ve QoS'a hâkim olmak verimli, kararlı Kubernetes workload'ları çalıştırmanın temelidir.

Request'ler ve limit'ler

Scheduling request'leri nasıl kullanır

QoS sınıfları (bellek baskısı altında eviction sırasını belirler)

Pratik rehberlik

Neden önemli

İlgili sorular