Kubernetes’te AI Agent Sandbox: Pratik Rehber
Şahsen, Geçen ay bir finans müşterimizde ilginç bir toplantı oldu. Ekip, LLM tabanlı birden fazla ajan çalıştırmak istiyordu — her biri ayrı iş yapan, birbirleriyle konuşan, kod üreten ve gerektiğinde onu çalıştıran ajanlar. İlk refleksleri neydi? Her ajan için bir StatefulSet tanımla, yanına headless Service koy, bir de PersistentVolumeClaim bağla. Sonuç? 15 ajan için 45 ayrı Kubernetes manifesti. Açık konuşayım, bu işin sonu yönetilemez bir karmaşaya gidiyordu.
Şöyle söyleyeyim, İşte tam burada SIĞ Apps altında geliştirilen Agent Sandbox projesi devreye giriyor (en azından benim gördüğüm tablo böyle). Proje daha yolun başında, evet; ama çözmeye çalıştığı dert baya gerçek (ciddiyim). Bu beni açıkçası şaşırtmadı değil, çünkü benzer sıkışmaları Türkiye’deki kurumsal müşterilerde birebir görüyorum. O yüzden konuyu kendi tecrübemle anlatayım dedim.
AI Ajanları Neden Farklı Bir Canlı?
Hani şöyle düşünün: klasik bir web API’si stateless çalışıyor. İstek gelir, cevap döner, konu kapanır. Kubernetes’in Deployment ya da ReplicaSet gibi soyutlamaları da tam bu dünya için gayet iyi oturuyor. Ama AI ajanları… İlginç, değil mi? şey, bunlar biraz başka türlü davranıyor.
İtiraf edeyim, bir AI ajanı uzun süre ayakta kalıyor. Bağlam tutuyor. Kod yazıp çalıştırıyor — ve o kodun güvenilir olup olmadığını siz de ben de çoğu zaman anında bilemiyoruz. Bazen boşta duruyor, sonra bir anda iş yükleniyor. Klasik request-response mantığından ziyade, daha çok bir dijital çalışma masası gibi düşünmek lazım. Kulağa basit geliyor ama değil.
Bence, İnanın, 2024’ün sonlarında bir telekom şirketinde PoC yapıyorduk. Müşteri destek ajanları oluşturmak istiyorlardı — her ajan bir müşteri oturumuna bağlıydı, konuşma geçmişini tutuyordu, gerektiğinde SQL sorgusu üretip çalıştırıyordu. Bunu vanilla Kubernetes ile yönetmeye kalkınca neler oldu biliyor musunuz? Neyse, her ajan için ayrı kaynak tanımı çıktı ortaya, güvenlik politikası ayrıydı, ağ izolasyonu ayrıydı… Açık konuşayım, operasyon tarafı iyice dağıldı.
Çok konuştum, örnekle göstereyim.
AI ajanları singleton, stateful ve çoğunlukla idle çalışan workload’lardır. Bu profil, Kubernetes’in geleneksel soyutlamalarıyla doğrudan örtüşmüyor.
Bence, Bir saniye — mesela ReplicaSet’i alın; çoklu kopya çalıştırmak için tasarlanmış. Burada ise tekil çalışan bir ajandan söz ediyoruz. StatefulSet’e gidebilirsiniz, evet; ama sırf 1’lik StatefulSet tanımlamak biraz garip duruyor. Üstüne bir de o ajanı durdurup sonra hızlıca geri açmak istediğinizde — suspend/resume mekanizması StatefulSet’te yok. İşte Agent Sandbox tam bu boşluğu hedefliyor.
Agent Sandbox Ne Getiriyor?
Şahsen, Peki içinde ne var? Temelde Sandbox CRD (Custom Resource Definition) var. Tek container’lık hafif bir çalışma ortamı sunuyor gibi görünüyor ama “hafif” deyip geçmeyin; altta iş gören birkaç parça var. Bazıları beklediğimden daha düzenli duruyor.
Güvenlik İzolasyonu
Bence, En kritik mesele zaten bu. Bir AI ajanı kod üretiyor ve çalıştırıyor; o kodun ne yapacağını önceden kestirmek zor oluyor. Sandbox tarafı gVisor veya Kata — ki bu tartışılır — Containers gibi runtime’ları doğal biçimde destekliyor. Yani kernel seviyesinde izolasyon alıyorsunuz; multi-tenant ortamlarda bu iş ciddi fark yaratıyor.
Geçen sene bir müşteride gVisor’ı Kubernetes üzerinde denemiştik; ayrı ayrı RuntimeClass tanımlayıp pod’lara atamak bayağı uğraştırmıştı açıkçası. Sandbox CRD’de bunun spec içine gömülmesi işleri sadeleştiriyor. İdare eder yani da tam burada çıkıyor.
Yaşam Döngüsü Yönetimi
Bence en hoş taraf burası. Bir ajanı suspend edebiliyorsunuz — yani pod kapanıyor ama durum korunuyor. Bu ne demek? Sonra ihtiyaç olduğunda resume ile tekrar ayağa kalkıyor; hem hızlı hem de maliyet tarafında etkisi hissediliyor. Node.js Addon’larını.NET Native AOT ile Yazmak yazımızda bu konuya da değinmiştik.
Bunu yaşayan biri olarak söyleyeyim, Düşünün: 100 tane ajanınız var. Herhangi bir anda sadece 10-15’i aktif oluyor (geri kalanlar boşta bekliyor). Klasik modelde hepsine kaynak ayırıyorsunuz; suspend mekanizmasıyla işe sadece aktif olanlar tüketim yapıyor. Bunu Bulut Maliyet Optimizasyonu: Hâlâ Geçerli Prensipler yazımda anlattığım FinOps yaklaşımıyla birlikte düşününce ortaya fena olmayan tasarruf çıkabiliyor. AI Maliyet Optimizasyonu: ROI’yi Gerçekten Artırmanın Yolu yazımızda bu konuya da değinmiştik. Foundry Agent’a MCP ile Özel Araç Bağlamak yazımızda da benzer taraftan bakmıştık.
Ve işler burada ilginçleşiyor.
Basit Bir Sandbox Tanımı
apiVersion: apps.kubernetes.io/v1alpha1
kind: Sandbox
metadata:
name: customer-support-agent-042
namespace: ai-agents
spec:
runtimeClassName: gvisor
container:
image: myregistry/support-agent:v2.1
resources:
requests:
cpu: "250m"
memory: "512Mi"
limits:
cpu: "1"
memory: "2Gi"
env:
— name: AGENT_ID
value: "042"
— name: LLM_ENDPOINT
value: "https://api.openai.com/v1"
storage:
size: 5Gi
storageClassName: fast-ssd
networkPolicy:
egress:
— to:
— ipBlock:
cidr: 10.0.0.0/8
ports:
— protocol: TCP
port: 443Böyle bakınca tek YAML dosyasında epey şey toplandığını görüyorsunuz : container var, storage var, runtime izolasyonu var, ağ politikası var.
Eskiden bunların her biri ayrı manifest olurdu; hatta bazen araya Secret ve RoleBinding de girerdi.
İlginç olan şu ki, Burada 15 ajan için düz hesapla yine manifest sayısı artar tabiî ama en azından yapı dağılmıyor (inanın bana)
Şöyle söyleyeyim, Bu operasyonel sadelik küçümsenecek iş değil.
Türkiye’deki Kurumsal Yapılar İçin Ne Anlama Geliyor?
Açık konuşayım mı? Türkiye’de Kubernetes kullanımı son 3-4 yılda baya yayıldı. Çoğu şirket hâlâ klasik workload’larda dönüyor — web uygulamaları, API’ler, batch job’lar falan.
AI agent workload’u ise işe henüz az yerde girdi.
Şöyle söyleyeyim, Ama değişim geliyor; hem de sessiz sessiz değil. Kubernetes AI Gateway WG: AI Trafiği Artık Standart yazımızda bu konuya da değinmiştik.
Bir dakika — bununla bitmedi.
Logosoft’ta son 6 ayda AI ile ilgili gelen taleplerin %60’ında “ajan” kelimesi geçiyor.
Müşteriler artık sadece “bir model çağırayım” demiyor; sürekli çalışan, karar verebilen ve araç kullanan bir şey istiyorlar.
Sonra da doğal olarak soruyorlar : bunu nereye koyacağız?
Evet, büyük bankalar ve telekom şirketleri zaten AKS (Azure Kubernetes Service) kullanıyor.
Agent Sandbox gibi bir CRD mevcut altyapının üstüne oturabiliyor.
Yeni platform öğrenmek gerekmiyor — bak şimdi asıl rahatlatıcı kısım bu.
Türkiye’de BT ekiplerinin yeni teknoloji benimseme hızı çoğu zaman ekip büyüklüğüyle paralel gidiyor; beş kişilik DevOps takımına “bir de şu platformu öğrenin” demek pek gerçekçi olmuyor doğrusu.
Daha fazla bilgi için SQL MCP Server: Veritabanını Ajanlara Açmanın Yolu yazımıza bakabilirsiniz.
Agent Sandbox mevcut Kubernetes cluster’larınıza CRD olarak ekleniyor.
Yeni platform kurmanıza gerek yok — kubectl apply ile başlayabilirsiniz.
Kimler İçin Mantıklı, Kimler İçin Erken?
Doğrusu, Kritik soru burada geliyor : gerçekten ihtiyacınız var mı? Her yeni teknolojide olduğu gibi önce bunu sormak gerekiyor. Yoksa insan kendini gereksiz yere tool peşinde koşarken buluyor.
Bunu biraz açayım.
| Senaryo | Agen Sandbox Uygun mu? | Alternatif |
|---|---|---|
| Kurum içi kullanım — 50+ ajan, multi-tenant | ⚠Status quo : | Status quo : |
| Status quo : |
Sıkça Sorulan Sorular
Agent Sandbox ile StatefulSet arasındaki fark nedir?
StatefulSet aslında birden fazla replika için düşünülmüş, genel amaçlı bir kaynak. Agent Sandbox ise tek container’lık bir şey — üstüne suspend/resume desteği geliyor, güvenlik izolasyonu da içine yerleşik. Yani tek bir ajanı yönetmek için StatefulSet + Service + PVC üçlüsünü ayrı ayrı tanımlamak yerine, Sandbox bunların hepsini tek bir YAML’da hallediyor. Bence bu tek başına büyük bir kolaylık (şaşırtıcı ama gerçek)
Şimdi gelelim işin can alıcı noktasına.
Agent Sandbox production’da kullanılabilir mi?
Açıkçası şu an (2026 Q2 itibarıyla) proje hâlâ alpha aşamasında. Test ve PoC ortamlarında kullanabilirsiniz, ama production için API stability garantisi henüz verilmiyor. SIĞ Apps’ın roadmap’ını takip edin — beta’ya geçtiğinde production değerlendirmesi yapmak çok daha mantıklı olur.
Hangi Kubernetes versiyonları destekleniyor?
Minimum Kubernetes 1.28 lazım. RuntimeClass desteği istiyorsanız — mesela gVisor ya da Kata için — node’larınızın da uygun runtime’larla yapılandırılmış olması gerekiyor. AKS, GKE ve EKS’de sorunsuz çalışıyor.
Suspend/resume sırasında veri kaybı oluyor mu?
Hayır, PersistentVolumeClaim üzerindeki veriler korunuyor. Ajan suspend edildiğinde pod siliniyor ama disk olduğu gibi duruyor (ciddiyim) (buna dikkat edin). Resume edilince yeni pod aynı PVC’yi mount ediyor ve kaldığı yerden devam ediyor. Şunu da es geçmeyin: in-memory state gidiyor — bunu ajanınızın kendi checkpoint mekanizmasıyla yönetmeniz gerekiyor.
Maliyet açısından ne kadar fark yaratıyor?
Tamamen kullanım profilinize bağlı. Ajanlarınız sürekli aktifse fark zaten minimal (inanın bana). Ama çoğu idle duruyorsa — ki AI ajanlarında bu tipik bir durum — suspend/resume ile compute maliyetlerinde %50-70 arası tasarruf mümkün. Tecrübeme göre projelerde ortalama %40-50 civarında bir düşüş görüyorum.
Evet, doğru duydunuz.
Kaynaklar ve İleri Okuma
Running Agents on Kubernetes with Agent Sandbox — Kubernetes Blog
Agent Sandbox GitHub Repository — kubernetes-sigs
Use gVisor with Azure Kubernetes Service — Microsoft Learn
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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
2 comments