Kubernetes'te Kaynak İstekleri ve Sınırları: CPU Kısıtlaması, OOMKilled ve QoS Sınıfları

Bir pod'a resources alanı yazmak basit görünür ama küme sağlığını en çok belirleyen iki kararı içinde taşır: zamanlayıcı bu iş yükünü hangi düğüme sığdıracak ve düğüm daralınca kim önce feda edilecek. İstek (request) ve sınır (limit) aynı satırlarda dursa da farklı katmanlarda çalışır. İstek yalnızca zamanlayıcının kullandığı bir rezervasyondur; kaynak gerçekten ayrılmaz, ama isteklerin toplamı düğümün ayrılabilir kapasitesini aşamaz. Sınır ise çekirdek düzeyinde uygulanır: CPU için cgroup kotası, bellek için cgroup tavanı. Bu ikisini karıştıran ekip ya boş dururken "dolu" görünen bir küme ya da yük altında sessizce yavaşlayan servisler elde eder.

CPU ve bellek aynı şey değil

CPU sıkıştırılabilir bir kaynaktır. Sınırı aşan konteyner öldürülmez, bekletilir. Kubelet CPU sınırını Linux CFS kotasına çevirir: varsayılan 100 ms'lik her dönemde konteynere sınır kadar CPU zamanı verilir, kota bitince süreç dönemin sonuna kadar askıya alınır. 500m sınır "her 100 ms'de 50 ms" demektir. Tek iş parçacıklı bir iş yükü için bu makul görünür; ama çok iş parçacıklı bir uygulama sekiz çekirdekte aynı anda koşarsa 50 ms'lik kotayı 6 ms'de tüketir ve dönemin kalan 94 ms'i boyunca durur. Ortalama CPU kullanımı grafikte yüzde 30 görünürken istek gecikmeleri katlanır. Bu kısıtlamanın (throttling) klasik belirtisidir ve çoğu ekip onu uygulama hatası sanır.

Bellek sıkıştırılamaz. Konteyner sınırı aşarsa çekirdeğin OOM killer'ı devreye girer, süreç 137 çıkış koduyla ölür ve pod durumunda OOMKilled yazar. Bekletme yoktur, uyarı yoktur. Ölçülen değer de sandığınız şey değildir: kubelet ve kubectl top çalışma kümesini (working set) gösterir, bu RSS artı aktif sayfa önbelleğidir. Çok dosya yazan bir konteyner, kodunun gerçekten tuttuğundan epey daha ağır görünür.

QoS sınıfları ve tahliye sırası

Kubernetes, istek ile sınır ilişkisinden her pod'a bir kalite sınıfı biçer:

• Guaranteed: her konteynerde CPU ve bellek için istek sınıra eşit.
• Burstable: en az bir istek ya da sınır var ama hepsi eşit değil.
• BestEffort: hiçbir şey yazılmamış.

Düğüm bellek baskısına girince kubelet önce BestEffort pod'ları, sonra isteğini aşan Burstable pod'ları tahliye eder; Guaranteed en sona kalır. Kritik bir servisi Burstable bırakıp "nasılsa isteğim var" demek, sınırın altında kalsa bile komşusunun taşkını yüzünden tahliye edilmeyi kabul etmektir. Düğüm kapasitesinin tamamı da kullanılamaz: ayrılabilir miktar, kapasiteden kubelet ve sistem rezervleri ile tahliye eşiği düşülerek bulunur. kubectl describe node çıktısındaki Allocatable satırı gerçek bütçedir; Capacity satırı değil.

Savunulabilir bir başlangıç noktası

1. Bellek için istek ile sınırı eşit yazın. Bellek taşkını komşuları etkilediği için sınır zorunlu; istek sınırdan düşük olursa pod "yeterli yer var" diye yerleştirilir ve gerçek tüketiminde düğümü baskıya sokar.
2. CPU için istek yazın, sınırı yalnız gerektiğinde koyun. İstek, CFS ağırlığı olarak adil paylaşımı zaten sağlar: düğüm dolduğunda herkes isteği oranında pay alır, boşken herkes serbestçe kullanır. Sınır koymak yalnızca gürültülü bir komşuyu kesin olarak kapatmak ya da Guaranteed sınıfına girmek için anlamlıdır.
3. Guaranteed gerekiyorsa CPU sınırını istekle eşitleyin ve tam sayı çekirdek isteyin; kubelet static CPU yöneticisi politikasıyla tam sayı isteyen Guaranteed pod'lara özel çekirdek verir ve kota kısıtlaması ortadan kalkar.

resources:
  requests:
    cpu: "500m"
    memory: "512Mi"
  limits:
    memory: "512Mi"

Ad alanı seviyesinde iki güvenlik ağı var. LimitRange, kaynak yazmayan pod'lara varsayılan atar ve BestEffort sınıfına düşmeyi engeller; ResourceQuota bir ekibin toplam rezervasyonunu sınırlar.

apiVersion: v1
kind: LimitRange
metadata:
  name: defaults
spec:
  limits:
    - type: Container
      defaultRequest:
        cpu: "100m"
        memory: "128Mi"
      default:
        memory: "256Mi"

Değeri nasıl bulursunuz

Tahmin etmeyin, ölçün. Bir hafta gerçek trafik altında container_memory_working_set_bytes ve rate(container_cpu_usage_seconds_total[5m]) serilerinin tepe ve 95. yüzdelik değerlerine bakın. Bellek isteğini tepeye yakın, CPU isteğini 95. yüzdeliğe koyun. Vertical Pod Autoscaler'ın öneri modu (updateMode: "Off") bu ölçümü sizin yerinize yapar ve pod'a dokunmadan önerilen değeri kendi durum alanına yazar; otomatik güncelleme modunu açmadan önce aylarca yalnız bu modu kullanmak iyi bir alışkanlıktır.

Kısıtlamayı yakalamak için oran şudur: container_cpu_cfs_throttled_periods_total / container_cpu_cfs_periods_total. Bu oran sürekli yüzde 25'in üstünde kalan bir konteyner ya sınırı hak etmiyor ya da sınır çok düşük. OOM için kube-state-metrics'in kube_pod_container_status_last_terminated_reason{reason="OOMKilled"} metriği yeniden başlatma nedenini saydırır; yalnız restart sayısına bakmak, probe kaynaklı yeniden başlatmalarla bellek ölümlerini birbirine karıştırır.

Tuzaklar

Çalışma zamanı sınırı bilmiyor. JVM konteyner sınırını okur ama varsayılan olarak bellek sınırının yalnızca dörtte birini yığın (heap) yapar; -XX:MaxRAMPercentage ile yükseltmezseniz 2 GiB verip 512 MiB kullanan bir servis elde edersiniz. Ters yönde, Go çalışma zamanı 1.25 sürümünden önce cgroup CPU kotasını hiç okumaz ve makinenin tüm çekirdeklerine göre GOMAXPROCS seçerdi; bu, yukarıdaki kısıtlama senaryosunun ta kendisidir. Go'da GOMEMLIMIT ortam değişkeni de çöp toplayıcının bellek sınırını görmesini sağlar; onsuz sınıra dayanmış bir servis OOM olur, yavaşlamaz.

Init konteynerleri hesabı değiştirir. Pod'un etkin isteği, sıradan konteynerlerin toplamı ile en büyük init konteynerinin isteğinden büyük olanıdır. Kurulum için 2 GiB isteyen bir init konteyneri, uygulamanız 256 MiB kullansa bile o düğümde pod yaşadığı sürece 2 GiB rezervasyon demektir.

Yüksek istek, boş küme. İstekler gerçek kullanımın çok üstündeyse zamanlayıcı düğümü dolu sayar, yeni pod'lar Pending'de bekler ve düğüm ekleyen otomatik ölçekleyici gereksiz makine açar. "Kümemiz yüzde 20'de ama pod yerleşmiyor" şikâyetinin nedeni neredeyse hep budur.

Bellek sınırı olmayan pod düğümü indirir. Sınırsız bir bellek sızıntısı önce komşuları tahliye ettirir, sonra kubelet'in kendisini sıkıştırır. Tek bir ad alanında bile bellek sınırı olmayan pod'a izin vermeyin; LimitRange tam bunun için var.

Sınır değişikliği yeniden başlatma demek. Kaynak alanı pod şablonunun parçasıdır; Deployment'ta değiştirmek yeni bir dağıtım başlatır. Yerinde yeniden boyutlandırma yeni sürümlerde geliyor ama henüz olgunlaşmadı; kapasite planını buna dayandırmayın.

Ne zaman bu tarif geçerli değil

Katı gecikme hedefi olan iş yükleri için (gerçek zamanlı medya, düşük gecikmeli veritabanı) "CPU sınırı koyma" tavsiyesi ters teper: düğüm dolduğunda adil paylaşım gecikmeyi öngörülemez yapar. Bu sınıf için Guaranteed artı static CPU yöneticisi doğru yoldur. Toplu işler için tam tersi geçerli: bellek isteğini düşük tutup sınırı yüksek bırakmak ve tahliyeyi kabullenmek daha ucuza gelir, çünkü iş yeniden kuyruğa girer ve kimse beklemez. Tarifin evrensel olan kısmı tek cümledir: hangi kaynağın sıkıştırılabilir olduğunu bilin ve sınırı yalnız orada gevşetin.