Kubernetes Node Swap ile Pod Yoğunluğunu 3 Katına Çıkarma
Kubernetes kümelerinde sınıra ilk dayanan kaynak çoğu zaman bellek oluyor; node’lar işlemci kapasitesini doldurmadan çok önce RAM’i tüketiyor. Ajan tabanlı (agentic) yapay zeka iş yükleri bu baskıyı daha da artırıyor, çünkü başlatılırken ve güvenilmeyen kod çalıştırırken büyük bellek ayırıyor, sonra bir sonraki istemi beklerken uzun uzun boşta kalıyorlar. Boşta duran ama fiziksel RAM’i işgal eden bellek hem pahalıya mal oluyor hem de bir node’a sığabilecek pod sayısını aşağı çekiyor. Kubernetes’in node swap desteği v1.34 ile Genel Kullanıma (GA) ulaştı, swap alanı hızlı NVMe SSD’lere yönlendirildiğinde node uyuyan belleği diske sayfalayıp çok daha fazla pod barındırabiliyor. Kubernetes blogundaki ölçümler üç farklı iş yükünde 3 kata varan yoğunluk artışı gösteriyor, çoğu durumda gecikme maliyeti ya çok az ya da hiç yok.
Node yoğunluğu sorunu nereden çıkıyor?
Bellek yoğun iş yüklerini planlayan yöneticinin önünde eski bir ikilem duruyor. Bellek limitlerini yüksek tutarsanız boşta duran RAM için pahalı altyapıyı israf edersiniz, düşük tutarsanız OOM (Out-Of-Memory) kill riskine girersiniz.
Otonom yapay zeka ajanları agent-sandbox gibi güvenli yürütme ortamlarıyla dağıtıldığında bu çatışma iyice görünür hale geliyor. Ajan pod’ları başlatma ve güvenilmeyen kodu çalıştırma aşamasında geniş bir bellek alanı istiyor, ama o kısa yoğun etkinlik biter bitmez kullanıcı istemini bekleyen uzun bir boşta kalma dönemine giriyor. Bu atıl durumu fiziksel RAM’de tutmak küme yoğunluğunu tavanlıyor, yapay zeka altyapısının faturasını da büyütüyor.
Swap neden uzun süre önerilmiyordu, şimdi ne değişti?
Kubernetes’te swap tarihsel olarak iki nedenle tavsiye edilmiyordu:
- Bellek muhasebesi: cgroup v1 altında bellek ve swap tek bir birleşik limit olarak ele alınıyor, operatör disk swap’i için bağımsız bir limit belirleyemiyordu. Bağımsız izleme olmayınca bir süreç büyük miktarda anonim belleği diske sayfalayabiliyor, konteynerin gerçek bellek kullanımı da öngörülemez ve izole edilmesi zor hale geliyordu. Kubernetes’in swap desteği, ayrı swap muhasebesi sunan cgroup v2’ye dayanarak bu sorunu çözüyor.
- Gecikme cezası: Yavaş dönen disklere sayfalama ciddi gecikme yaratıyordu. Hızlı NVMe Local SSD’ler bu maliyeti büyük ölçüde ortadan kaldırıyor.
İki değişiklik bir araya gelince, küme kararlılığından ödün vermeden pod yoğunluğunu artırmak ve bellek sıçramalarına karşı tampon oluşturmak pratik hale geliyor. Node swap, trafik sıçramalarında veya ağır bellek aşırı tahsisinde bir şok emici gibi çalışıyor.
Üç iş yükünde ölçüm sonuçları
Local SSD destekli node swap’in performans sınırlarını ve tasarruf potansiyelini ölçmek için üç iş yükü kategorisi incelendi: CI/CD boru hatlarını temsil eden klasik derleme işi, yüksek yoğunluklu tarayıcı sandbox’ları ve izole Python çalışma ortamları.
| İş yükü profili | Swap’siz temel kapasite | Local SSD swap ile kapasite | Yoğunluk değişimi |
|---|---|---|---|
| Linux CI/CD kernel derlemesi | 600 MB RAM limiti | 300 MB RAM limiti | -%50 RAM ayak izi |
| Headless Chrome (Kata) | 40 eşzamanlı pod | 50 eşzamanlı pod | +%25 pod yoğunluğu |
| Headless Chrome (gVisor) | 80 eşzamanlı pod | 160 eşzamanlı pod | +%100 pod yoğunluğu |
| Python sandbox (gVisor) | 80 eşzamanlı pod | 240 eşzamanlı pod | +%200 pod yoğunluğu |
1. Klasik iş yükü: Linux kernel derlemesi
Ajan mimarilerine geçmeden önce swap, tam bir Linux 6.1.1 kernel derlemesiyle klasik toplu iş yüklerinde doğrulandı. Kernel derlemesi eşzamanlı işçi iş parçacıkları kullanıyor, derlenmiş nesne dosyalarını tutmak için bellekte şişiyor, kısa süren bağlama (linking) aşamasında da büyük bir bellek sıçraması istiyor.
Bu davranış kurumsal CI/CD boru hatlarının bellek profilini yansıtıyor. Boru hattı ilerlerken daha önce derlenmiş nesneler bellekte atıl kalıyor, yani CI/CD işleri kullanılmayan fiziksel RAM’i biriktiriyor; tam da node swap ile sıkıştırmaya uygun bir desen.
Swap’siz temel node’da derleme sırasında OOM çökmesini önleyen en düşük bellek limiti 600 MB oldu. Swap Local SSD’ye yönlendirilince konteyner bellek limiti %50 azalıp 300 MB’a indi ve yürütme yavaşlamadı, aksine iş 374 saniyede tamamlandı; temel senaryoda bu süre 433 saniyeydi. Limiti 200 MB’a kadar sıkıştırmak ise aktif çalışma kümesini swap’e itti, uzun I/O bekleme süreleri oluştu ve yürütme süresi %40’ın üzerinde arttı. Sınır burada net görünüyor: swap, ani bellek ihtiyacı için bir sigorta poliçesi, aktif RAM’in yerine geçmiyor.
2. Yüksek yoğunluklu ajan iş yükleri: headless tarayıcılar
Yapay zeka ajanları sıklıkla Chromium üzerinden headless tarayıcı kullanıyor. Dışarıdan gelen kodu çalıştırmak ise standart Linux namespace’lerinden daha sıkı bir izolasyon gerektirebiliyor, bu yüzden farklı konteyner çalışma zamanları karşılaştırıldı. Varsayılan çalışma zamanına ait ham loglar ve test yöntemleri Agent Sandbox GKE Swap dizininde bulunuyor.
Sandbox’siz temel sınır (runc): Güvenlik çalışma zamanlarının ek yükü olmadan ortamın sınırlarını görmek için düz runc konteynerleri c4-standard-32 bir node üzerinde (32 vCPU, 120 GB RAM) tarandı. Swap olmadan node fiziksel belleği tüketti ve 512 pod’un ötesinde başarısız oldu. Local SSD swap etkinleştirildiğinde aynı node 768 eşzamanlı pod’u taşıdı.
Gelişmiş güvenlik çalışma zamanları (gVisor, Kata Containers): Sıkı sandbox’lama bellek ek yükünü artırır, normalde pod yoğunluğunu da düşürür. Swap bu ek yükü doğal biçimde soğuruyor. Swap’siz bir gVisor ortamı 80 pod’da sert sınıra çarptı, Local SSD swap ile tek node üzerinde 160 eşzamanlı gVisor pod’u çalıştırılabildi. Kata Containers microVM’leri de swap olmadan 40 eşzamanlı pod’da fiziksel RAM’i tüketirken, GCP Local SSD swap ile CPU doygunluğuna ulaşılana dek 50 kararlı Kata microVM’e çıkıldı.
Bir ayrıntı önemli. Bu azami yoğunluklarda pod başına gecikme artışının ana nedeni swap I/O değil, pod’ların CPU için yarışması. Belirli bir gecikme hedefine göre ayar yapan operatör buradaki tepe değerlerin altında bir yoğunlukta çalışır ve orantılı olarak daha düşük bir gecikme maliyeti görür. gVisor ve Kata için ayrıntılı mimari çözümleme ve yoğunluk metrikleri Agent Sandbox GKE Swap Runtimes dizininde yer alıyor.
3. İzole Python çalışma ortamları
Node swap’in avantajı, güvenilmeyen kodu izole biçimde çalıştıran ortamlara da uzanıyor. Bu testte eşzamanlı Python sandbox oturumları MovieLens 20M veri kümesinden 5 milyon satırı analiz edecek şekilde çalıştırıldı, her yürütme yaklaşık 375 MiB yerleşik bellek ayak izi istiyordu. Ayrıntılı ölçeklenme sonuçları ve dağıtım kodu Agent Sandbox GKE Swap Python Density dizininde inceleniyor.
Swap olmadan yoğun eşzamanlı sıçramalar fiziksel belleği tüketti, node 80 eşzamanlı oturumda sert RAM sınırına çarpıp başarısız oldu. Local SSD swap etkinleştirildiğinde uyuyan anonim bellek diske aktarıldı, fiziksel RAM serbest kaldı, node’un page cache’i korundu. Node sonunda 240 eşzamanlı izole Python sandbox’ına ölçeklendi, yani yoğunluk 3 katına çıktı. Tarayıcı iş yüklerinde olduğu gibi burada da tepe yoğunluktaki gecikme artışı esas olarak sandbox’ların CPU için yarışmasından kaynaklandı.
Nasıl etkinleştirilir?
Geliştirici ortamları, tarayıcı test çiftlikleri, JVM uygulamaları veya yapay zeka yürütme ortamları işleten ekipler için Local SSD swap, yoğunluk verimliliğini katlayabilir. Kubernetes v1.34 ve sonrasında node swap Genel Kullanıma açık, kubelet yapılandırmasıyla etkinleştiriliyor:
kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
failSwapOn: false
memorySwap:
swapBehavior: LimitedSwap
Bu upstream yapılandırmayı bulut sağlayıcınızın yüksek hızlı yerel diskiyle eşleştirdiğinizde dinamik bellek dengelemesi elde edersiniz. Google Kubernetes Engine’de bunun karşılığı, Local SSD profilleri üzerinde yapılandırılan Node Memory Swap ve yerel olarak destekleniyor.
Kazanımı görmek için iş yüklerini Burstable QoS ile yapılandırmak gerekiyor, yani konteynerin bellek limitini isteğinden (request) yüksek ayarlamak. Node, uygulamanın atıl bellek kullanımına göre hızlı swap alanını otomatik paylaştırırken aktif süreçleri yanıt verebilir durumda tutuyor.
Pratikte ne anlama geliyor?
Kubernetes ekosistemi ajan çağına geçerken yöneticiler, sabit donanım bellek sınırları ile yapay zeka iş yüklerinin sıçramalı davranışı arasında sıkışıyor. Agent Sandbox gibi çerçeveler güvenilmeyen ajanları çalıştırmak için gereken güvenlik izolasyonunu sağlıyor, ama bu izolasyon geleneksel olarak büyük miktarda atıl bellek ek yükü istiyor.
kubelet’i LimitedSwap ile yapılandırıp swap’i Local SSD’ye yönlendirmek bu çatışmayı hafifletiyor. Hızlı swap, boştaki ajanların uyuyan durumlarını diske aktarıyor, böylece aynı altyapı üzerinde güvenlik sınırlarından ödün vermeden pod yoğunluğu ve node kullanımı artıyor. Ölçümlerin gösterdiği sınır da ortada duruyor: swap ani bellek talebi için tampon görevi görüyor, aktif çalışma kümesini diske itecek kadar agresif sıkıştırma yapıldığında ise I/O bekleme süreleri hızla cezaya dönüşüyor.
Kaynaklar ve İleri Okuma
- Kubernetes Blog — Scaling Kubernetes Workloads with Node Swap (orijinal yazı)
- kubernetes-sigs/agent-sandbox deposu
- Google Kubernetes Engine — Node Memory Swap dokümantasyonu
- Kubernetes Blog RSS akışı
- Kubernetes v1.37 ile Node Lifecycle Conditions dönemi
- Node Readiness Controller: Kubernetes’te Ready’nin Ötesi
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
Yorum gönder