Kubernetes Kaynak Yönetimi: Request, Limit ve VPA Ayarları

Hepimiz o sancılı anı en az bir kez yaşamışızdır: Hafta sonu tam kahvenizden ilk yudumu almışken, Slack veya PagerDuty üzerinden bir “Pod crashed” uyarısı düşer. Hemen terminale koşup cluster’a sızarsınız, kubectl describe pod komutunu yapıştırırsınız ve karşınızda o meşhur ibareyi görürsünüz: OOMKilled (Exit Code 137). Ya da daha sinsisi; CPU kullanımı %10 seviyelerindeyken uygulamanın response time’ları bir anda saniyelere fırlar, çünkü arkada amansız bir CPU throttling savaşı dönmektedir.

Kubernetes dünyasında kaynak yönetimi (resources), teoride çok basit görünse de pratikte prod ortamlarının en büyük baş belasıdır. Bu makalede, deneyimli bir devops mühendisinin gözünden, kubernetes üzerinde CPU/Memory dengesini nasıl kuracağımızı, vpa (Vertical Pod Autoscaler) ile kaynak yönetimini nasıl otomatize edeceğimizi ve throttling/OOMKill canavarlarıyla nasıl savaşacağımızı derinlemesine ele alacağız.

Request ve Limit: scheduler’ın Terazi Hassasiyeti

Kubernetes dünyasında kaynakları tanımlarken iki temel kavram kullanırız: requests ve limits. Bunların arasındaki farkı netleştirmek, sistemin kararlılığı için atılacak ilk adımdır.

• Request: Bir pod’un schedule edilebilmesi için garanti edilen minimum kaynak miktarıdır. Kubernetes scheduler, bir node üzerinde pod’u konumlandırırken sadece bu değere bakar. Eğer node üzerinde boşta yeterli “request” kapasitesi yoksa, pod o node’a yerleşemez (Pending durumunda kalır).
• Limit: Bir pod’un fiziksel olarak tüketebileceği maksimum kaynaktır. Pod bu sınırı aşmaya çalıştığında kernel seviyesinde kısıtlamalar devreye girer.

QoS (Quality of Service) Sınıfları Neden Önemli?

Request ve limit değerlerini nasıl tanımladığınız, Kubernetes’in podunuza atayacağı QoS sınıfını belirler. Node üzerinde kaynak darboğazı yaşandığında, kubelet ilk olarak hangi pod’u feda edeceğine (eviction) bu sınıfa göre karar verir:

1. Guaranteed (Garantili): Pod içerisindeki tüm container’ların request ve limit değerleri birbirine eşittir (hem CPU hem Memory için). Kubernetes bu pod’ları en son gözden çıkarır. Veritabanları ve stateful servisler için idealdir.
2. Burstable (Esneyebilir): Request değeri limit değerinden küçüktür veya sadece request tanımlanmıştır. Web uygulamalarımızın %90’ı bu sınıfa girer. Node sıkıştığında, limitlerine yaklaşan burstable pod’lar ilk hedef tahtasındadır.
3. BestEffort (Gönlünden Ne Koparsa): Ne request ne de limit tanımlanmıştır. Node üzerinde kaynak bittiği an, kubelet bu pod’ları acımadan öldürür. Prod ortamında asla ama asla kullanılmamalıdır!

# Burstable QoS sınıfına örnek bir pod tanımı
apiVersion: v1
kind: Pod
metadata:
  name: billing-service
  namespace: production
spec:
  containers:
  - name: app
    image: internal/billing:v2.1.0
    resources:
      requests:
        memory: "256Mi"
        cpu: "200m"
      limits:
        memory: "512Mi"
        cpu: "1000m"

CPU Throttling ve OOMKill: Sessiz Katiller

Memory ve CPU, işletim sistemi kernel’ı tarafından farklı şekillerde yönetilir. Bu fark, pod’larımızın hayatta kalma mücadelesini doğrudan etkiler.

OOMKill (Out of Memory)

Memory, sıkıştırılamaz (non-compressible) bir kaynaktır. Bir pod, kendisine tanımlanan memory limit değerini aşarsa, kernel’ın oom-killer mekanizması devreye girer ve pod’u anında öldürür. Pod’unuz durduk yere 137 exit kodu ile çöküyorsa, memory limitiniz uygulamanın anlık yük altında ihtiyaç duyduğu heap size’a yetmiyor demektir.

Bunu debug etmek için şu komutla son çöken pod’ların nedenlerine bakabilirsiniz:

kubectl get pods -n production -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.containerStatuses[*].lastState.terminated.reason}{"\n"}{end}' | grep OOMKilled

CPU Throttling

CPU ise sıkıştırılabilir (compressible) bir kaynaktır. Pod’unuz CPU limitine ulaştığında işletim sistemi onu öldürmez; bunun yerine pod’a tahsis edilen CPU zaman dilimlerini (CFS shares) kısar. Buna throttling denir.

Uygulamanız çökmez ama bir anda istekleri işlememeye başlar, thread’ler kuyruğa girer ve latency tavan yapar. Birçok junior mühendis bu durumu fark edemez çünkü pod “Running” durumundadır ve CPU kullanımı %100 görünmez (çünkü limit bazlı kırpılmıştır).

Prometheus üzerinde CPU throttling olayını yakalamak için şu PromQL sorgusunu kullanabilirsiniz:

sum(rate(container_cpu_cfs_throttled_seconds_total[5m])) by (pod, container) / sum(rate(container_cpu_usage_seconds_total[5m])) by (pod, container) * 100

Eğer bu oran %5’in üzerindeyse, uygulamanız ciddi şekilde yavaşlatılıyor demektir. Limit değerinizi artırmanın vakti gelmiştir.

VPA (Vertical Pod Autoscaler) ile Otomatik Kaynak Yönetimi

Yazılımcılara “Uygulamanız ne kadar kaynak tüketiyor?” diye sormak, bir çocuğa “Ne kadar dondurma istersin?” diye sormaya benzer. Cevap hep “Çok!” olur. İşte bu noktada vpa devreye giriyor. VPA, pod’ların geçmiş kaynak tüketimlerini izleyerek en ideal request ve limit değerlerini otomatik olarak hesaplar.

VPA üç ana bileşenden oluşur:

• Recommender: Tarihsel metrikleri (Prometheus veya Metrics Server üzerinden) inceleyerek ideal kaynak önerilerini hesaplar.
• Updater: Eğer bir pod önerilen değerlerin çok dışındaysa, pod’u silerek yeni değerlerle yeniden ayağa kalkmasını tetikler (eğer mode: Auto ise).
• Admission Controller: Pod yeniden oluşturulurken mutasyon aşamasında araya girer ve yeni request/limit değerlerini pod spec’ine enjekte eder.

Aşağıda prod ortamında güvenle kullanabileceğiniz bir VPA konfigürasyon örneği yer alıyor:

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: auth-service-vpa
  namespace: production
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: auth-service
  updatePolicy:
    updateMode: "Auto" # "Off", "Initial" veya "Auto" yapabilirsiniz.
  resourcePolicy:
    containerPolicies:
      - containerName: '*'
        minAllowed:
          cpu: "100m"
          memory: "128Mi"
        maxAllowed:
          cpu: "2000m"
          memory: "4Gi"
        controlledResources: ["cpu", "memory"]

Pro-Tip: Eğer pod’larınızın durduk yere restart olmasını istemiyorsanız, updateMode: "Off" olarak ayarlayın. VPA sadece öneri (recommendation) üretecektir. Siz de bu önerileri inceleyerek (kubectl describe vpa auth-service-vpa) manuel olarak güncelleme yapabilirsiniz.

VPA ve HPA Çelişkisi: İki Kaptan Bir Gemiyi Batırır

Eğer cluster mimarinizde hem hpa (Horizontal Pod Autoscaler) hem de VPA kullanıyorsanız dikkat etmeniz gereken çok kritik bir kural var: İkisini de aynı kaynak metriğine (örn: CPU kullanımına) göre ölçeklenecek şekilde ayarlayamazsınız!

Eğer HPA CPU kullanımına göre pod sayısını artırmaya çalışırken, VPA de aynı CPU metriğine bakıp pod’un dikey boyutunu büyütmeye çalışırsa, sistem kararsız bir döngüye girer. HPA pod ekler, VPA pod’u yeniden başlatıp büyütür, tam bir kaos yaşanır.

Bu Çıkmazdan Nasıl Kurtuluruz?

1. HPA’yı Custom/External Metriklere Geçirin: HPA’yı CPU/Memory yerine Prometheus üzerinden gelen saniye başına istek sayısı (RPS), kuyruk uzunluğu (RabbitMQ queue size) veya aktif veritabanı bağlantı sayısı gibi işlevsel metriklere göre ölçeklendirin. VPA ise arkada sessizce pod’ların fiziksel limitlerini optimize etsin.
2. VPA’yı Sadece Öneri Modunda Çalıştırın: VPA’yı updateMode: "Off" modunda bırakıp, Goldilocks gibi open-source araçlar kullanarak sadece doğru kaynak değerlerini bulmak için bir pusula olarak kullanın.

Altın Kurallar ve Best Practices

• CPU Limitlerini Çok Sıkı Tutmayın (Veya Hiç Koymayın): Modern Kubernetes topluluklarında (özellikle büyük ölçekli altyapılarda) CPU limitlerinin kaldırılması tartışılıyor. Çünkü CPU limitleri CFS throttling nedeniyle gereksiz latency oluşturabiliyor. Bunun yerine yüksek CPU request’i tanımlayıp limit koymamak (veya çok yüksek tutmak) node üzerindeki işlemci gücünü daha efektif kullanabilir. Ancak Memory limitleri kesinlikle zorunludur!
• Overcommit Oranını İyi Yönetin: Node’larınızdaki toplam Memory limitlerinin, fiziksel node kapasitesini aşırı derecede geçmesine (overcommit) izin vermeyin. Aksi takdirde bir yük anında tüm node kilitlenebilir ve kubelet pod’ları kontrolsüzce öldürmeye başlar.
• Liveness ve Readiness Probe’lara Dikkat Edin: Probe’ların kullandığı endpoint’lerin yüksek CPU/Memory tüketmediğinden emin olun. Throttling anında probe’lar timeout’a düşerse, Kubernetes sağlam podunuzu “unhealthy” sayıp restart döngüsüne sokabilir.

Kubernetes üzerinde kaynak yönetimi, sürekli izlenmesi ve dinamik olarak ayarlanması gereken canlı bir süreçtir. VPA gibi otomasyon araçlarını sisteminize entegre ederek hem cloud maliyetlerinizi düşürebilir hem de o meşhur cumartesi gecesi uykularınızı garanti altına alabilirsiniz.