Bulut Altyapı

Agent Sandbox: Kubernetes’te AI Agent’ları Çalıştırmak

Geçen ay Logosoft’ta bir bankacılık müşterimizle oturmuştuk. Konu netti: ürettikleri bir LLM tabanlı asistanı production’a almak istiyorlardı, ama mimarı taraf bir yerde tıkanmıştı (ben de ilk duyduğumda şaşırmıştım). “Aşkın bey, biz bu (belki yanilıyorum ama) agent’ları nereye koyacağız? Lambda mı, container mı, VM mi?” diye sordular. Cevabım kısa oldu: Kubernetes. Ama hemen ardından küçük bir parantez açtım — “Sadece klasik Deployment ile değil. İşler biraz değişti.” Evet, tam da öyle (evet, doğru duydunuz)

İşte burada Agent Sandbox devreye giriyor. SIĞ Apps altında geliştirilen, henüz erken aşamada olan ama bence önümüzdeki 12 ayda baya konuşulacak bir proje. Bugün bunu didik didik edeceğiz. Hem teknik tarafta ne sunduğunu, hem de Türkiye’deki kurumsal yapılarda neye denk geldiğini konuşalım (bizzat test ettim)

AI v1’den AI v2’ye: Mimarı Olarak Ne Değişti?

Yani, Bakın şimdi, durumu fazla süslemeden koyalım. İlk nesil generative AI uygulamaları aslında oldukça düz şeylerdi; istek gelir, model birkaç on milisaniye çalışır, cevap döner ve container kapanırdı. Stateless. Tek atımlık. Hani ne farkı var diyorsunuz, değil mi? Bildiğimiz REST API mantığı yani.

Şunu söyleyeyim, Ama agent dediğiniz şey öyle değil. Bir AI agent uzun süre ayakta kalmak zorunda oluyor, bağlam tutuyor, dış araçları (tools) kullanıyor, kod yazıp çalıştırıyor, başka agent’larla konuşuyor. Resmen küçük bir dijital çalışma alanı gibi davranıyor. Üstelik çoğu zaman boş durduğunu da unutmayalım — aktif olduğu anlar kısa burst’ler hâlinde geliyor.

Bu farkı klasik Kubernetes primitive’leriyle modellemek mümkün mü? Evet, mümkün; ama açık konuşayım baya uğraştırıyor. Her agent için ayrı StatefulSet (size: 1), headless Service, PVC… 10 agent için belki idare eder ama 500 olunca iş çığrından çıkıyor. Geçen sene bir e-ticaret müşterimizde buna benzer bir şeye girdik — altı ay sonra mimariyi söküp yeniden kurduk (ciddiyim)

Kısa bir not düşeyim buraya.

“Geleneksel Kubernetes objelerini birbirine bağlayarak agent çalıştırmak, kürdanla köprü yapmaya benziyor. İşliyor — bir noktaya kadar. Sonra dağılıyor.”

Agent Sandbox Tam Olarak Ne Sunuyor?

İşin özünü tek cümlede söyleyeyim: Agent Sandbox projesi Sandbox adında yeni bir Custom Resource Definition (CRD) getiriyor ve bunu AI agent runtime’ları için özel olarak tasarlıyor. Singleton workload’lar için yani; stateful olanlar için; uzun ömürlü olup çoğu zaman idle kalan işler için.

Kısaca “agent için Pod” diyebilirsiniz ama Pod’dan biraz daha fazlası var burada. Üç ana yetenek öne çıkıyor:

1. Güvenli İzolasyon (Bu Olmazsa Olmaz)

Düşünün: Agent’ınız LLM’den kod alıyor ve önü çalıştırıyor (ciddiyim). Bu kod sizin yazdığınız kod değil; LLM’in ürettiği kodu koşturuyorsunuz aslında. Yani kendi infrastructure’ınızda untrusted code çalıştırıyorsunuz ve bu kulağa pek rahat gelmiyor.

Sandbox CRD bu problemi çözmek için gVisor. Kata Containers gibi alternatif runtime’ları native olarak destekliyor. Manifest’te “bu agent gVisor altında koşsun” diyorsunuz, geri kalanını sistem toparlıyor; kernel izolasyonu da network izolasyonu da paket hâlinde geliyor gibi düşünebilirsiniz.

Ben şahsen en kritik kısmın bu olduğunu düşünüyorum çünkü AZ-500’e hazırlanırken de defalarca gördük ki multi-tenant yapılarda container escape senaryoları hâlâ ciddiyetini koruyor; standart runc ile AI agent çalıştırmak — açık konuşayım — biraz pervasızlık ölür.

2. Yaşam Döngüsü Yönetimi (Suspend/Resume)

Beni en çok heyecanlandıran nokta burasıydı işte. Daha açık söyleyeyim, bir AI agent saatlerce idle kalabiliyor; kullanıcı görev veriyor, agent işi bitiriyor ve sonra beklemeye geçiyor. Bekleme sırasında CPU yemesinin pek anlamı yok (şaşırtıcı ama gerçek)

Sandbox API size agent’ı suspend edip state’i diske almayı ve sonra hızlıca resume etmeyi sağlıyor / en azından hedeflediği şey bu / maliyet tarafında da ciddi fark yaratabilecek türden bir yaklaşım bu sanırım… Sonra sayıya gireceğim zaten. Daha fazla bilgi için ları ile ilgili önceki yazımız yazımıza bakabilirsiniz.

3. Identity ve Persistent State

Her agent’ın kendine ait kalıcı kimliği ve “scratchpad” dediğimiz çalışma alanı oluyor; böylece restart sonrası nereden devam edeceğini biliyor ya da en azından bilmesi hedefleniyor diyelim daha dürüst olurum. Konuşma geçmişi var, kullandığı araçlar var, ürettiği dosyalar var — hepsi yerinde kalabiliyor.

Klasik Yöntemle Karşılaştırma: Pratik Bir Bakış

Lafı gevelemeden somut tabloyu koyayım çünkü rakam bazen her şeyi anlatıyor gibi davranıyor ama bazen de kandırabiliyor; yine de burada faydalı olacak gibi duruyor: Bu konuyla ilgili PostgreSQL’in Geleceği: Microsoft’tan Commit’ten Bulut’a yazımıza da göz atmanızı tavsiye ederim. Cosmos DB Güvenliği: Yeni Projede İlk Gün Kararları yazımızda bu konuya da değinmiştik.

Kriter Klasik (StatefulSet + PVC + Service) Agent Sandbox CRD
YAML satır sayısı (agent başına) ~120 satır ~25 satır
Izolasyon seviyesi Muhteşem değil / manuel runtimeclass ayarı gerekir Sistem içinden geliyor (gVisor/Kata)
Suspend/Resume Yok (kendin yazacaksın) Dahili olarak var
Tatilde bekleyen maliyet Evet pod ayakta = CPU/RAM tüketimi sürer gider Suspended durumda sıfıra yakın seyreder
100 agent için operasyonel yük Epey yüksek ölür Daha düşük kalır

Büyük fark var gibi görünüyor değil mi? Var evet; ama burada küçük bir fren yapayım çünkü proje henüz development‘ta ilerliyor ve production’a “yarın basalım” denecek durumda değil bana sorarsanız. PoC ortamında, internal tooling tarafında, lab’da denenmeli; önce orada yürüsün sonra üretime bakılır.

Basit Bir Sandbox Manifest Örneği

Neye benzediğini göstereyim dedim ama syntax tarafının hızlı değişebileceğini de not düşeyim; proje canlı canlı evriliyor sonuçta:

apiVersion: agents.x-k8s.io/v1alpha1
kind: Sandbox
metadata:
name: customer-support-agent-042
namespace: agents-prod
spec:
runtime:
class: gvisor # ya da kata-containers
image: registry.local/agent-runtime:1.4.2
resources:
requests:
cpu: "200m"
memory: "512Mi"
limits:
cpu: "2"
memory: "4Gi"
persistence:
enabled: true
size: 5Gi
lifecycle:
idleTimeout: 15m
suspendOnIdle: true
identity:
serviceAccount: agent-sa

Baktığınızda görüyorsunuz zaten mesele şu yatakta toplanmış durumda: suspend mantığı, persistence, izolasyon… hepsi tek resource altında birleşmiş. Klasik YAML yığınına göre baya daha okunur duruyor, itiraf edeyim şaşırdım açıkçası. Bu konuyla ilgili Claude Opus 4.8 GitHub Copilot’ta: Sahadan İlk İzlenimler yazımıza da göz atmanızı tavsiye ederim.

Türkiye’deki Kurumsal Yapılar Açısından Ne Anlama Geliyor?

Peki neden bizim için önemli? Şöyle söyleyeyim: son sekiz dokuz aydır Microsoft Azure danışmanı olarak girdiğim neredeyse her müşteri toplantısında AI agent konusu açılıyor. Ama Türkiye’deki yapıların iki belirgin gerçeği var; bunu kabul etmeden ilerleyemeyiz. Visual Studio 2026 C++ Yenilikleri: 18.1’den 18.6’ya Saha yazımızda bu konuya da değinmiştik.

İşin garibi, Bir:Çoğu kurum hâlâ AKS (Azure Kubernetes Service) konusunda yeni yeni rahat nefes alıyor. Daha klasik workload’ları doğru düzgün taşırken üstüne bir de “agent CRD” eklemek operasyon ekibi için ayrı öğrenme eğrisi demek. Bu yüzden müşterilere şunu söylüyorum: önce AKS Fleet Manager Cross-Cluster Networking:Saha Notlarıwritmda anlattığım temel cluster yönetimini oturtun, sonra ajan katmanına geçin; yoksa ekip gereksiz yorulur.

İtiraf edeyim, İkinci:Türkiye’de KVKK ve regülasyon baskısı yüksek; özellikle finans ve sağlık tarafında. AI agen’tın “untrusted code çalıştırdığını” teknik arka planını bilmeyen bir komiteye anlatmaya kalkınca ortalık karışabiliyor, deneyen bilir. Bu yüzden gVisor/Kata izolasyonu bizim tarafta sıradan feature değil, doğrudan satış argümanı hâline geliyor; “müşteri verisine dokunmadan kendi sandbox içinde çalışıyor” diyebilmek gerçekten işe yarıyor.

Maliyet Hesabı:Tl Bazında Düşünelim

diyelim ki Azure’da yüz tane agen çalıştiriyorsunuz, her biri iki vCPU artı dört GB RAM istiyor. Standart D2s v5 fiyatlarıyla kaba hesapta VM başina aylık doksan ile doksan beş USD arası gidip geliyorsunuz; yüz tane olunca toplam dokuz bin USD civarına çıkıyorsunuz. TL hesabıyla bakınca kabaca aylık üç yüz elli — üç yüz seksen bin TL ediyor.

Şimdi Agent Sandbox’ın suspend mekanizmasını düşünelim; ajanların yüzde yetmişinin zamanın yüzde sekseninde idle kaldığını varsaysak bile(çok uçuk değil aslında), teorik tasarruf kabaca yüzde elli — elli beş bandına gelebiliyor. Yani aylık yaklaşık yüz seksen — iki yüz bin TL cebinizde kalabilir; yılda bakınca iki buçuk milyon TL civarı eder. Küçük-orta ölçekli banka için bile az para değil, açık konuşayım insanın aklı dönüyor biraz.

💡 Bilgi:Suspend/resume mantığı her workload için uygun değil.Bazen olay tam tersine döner.Eğer ajanlariniz sürekli stream eden veri isliyorsa veya WebSocket benzeri kalıcı bağlantılar tutuyorsa,bunun sana pek faydası olmaz.O yüzden önce kendi kullanım profilinizi ölçün.

Evet.

💡 Bilgi:Suspend/resume mantığı her workload için uygun değil.Bazen olay tam tersine döner.Eğer ajanlariniz sürekli stream eden veri isliyorsa veya WebSocket benzeri kalıcı bağlantılar tutuyorsa,bunun sana pek faydası olmaz.O yüzden önce kendi kullanım profilinizi ölçün.

Evet.
Sonra bakarsınız.”

Startup mi Enterprise mi? Doğru Stratejiyi Seçmek

Bu kısım genelde atlanıyor ama bence kritik.Çünkü herkesin hikâyesi aynı değil.

Küçük Ekipseniz / Startup’sanız:

  • Şimdilik Agent Sandbox’i production’da kullanmayın.Henüz erken.
  • Bunun yerine basit Deployment + Redis state pattern’iyle başlayin
  • Ama API tasarımınızı Sandbox CRD’ye benzer şekilde düşünün-gecis kolay olsun
  • gVisor’i şimdiden öğrenin,sınırda lazım olacak
    ?>
    • Kurumsal Yapidaysanız:

      • Bir PoC ekibi kurun, Agent Sandbox’i izole cluster’da deneyin
      • Platform engineering ekibinizi şimdiden egitin(CRD,kontrolcü pattern,runtime classes)
        Compliance ekibiyle “untrusted code execution” konusunu erken konusun-sonradan kavga olmasın
        Agent’lar arası iletişim için A2A v1 Geldi: Agent’lar Artık Aynı Dili Konuşuyor] protokolünü mimarı plana alın

          Saha Notu:Ilk Denemede Karşılaştığım Sorun

          Geçen hafta kendi lab ortamimde Agent Sandbox’i kurmaya çalıştım.Kind cluster,gVisor runtime class hazırdı.Sandbox CRD’yi apply ettim…ve patladı.RuntimeClass not found hatası.Bir saat boyunca her şeyi kontrol ettim-manifest doğru, CRD yüklü.

          Sonunda anladım:gVisor’i host node’a kurmuştum ama containerd config’indeki handler tanımını eksik bırakmıştım./etc/containerd/config.tomldoscasinda \plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runscbölümünü eklemem gerekiyordu.Sonra containerd restart edildi,dahası her şey yürüdü.

          Çıkardığım ders şu oldu: Agent Sandbox güzel bir abstraksiyon getiriyor ama alttaki runtime kurulumu hâlâ sizin omuzunuzda.Her şeyi Helm install yaptım,bitti diye beklerseniz hayal kırıkligi yaşarsınız.

          Eksik Yanlar Ve Endişelerim

          Sadece övmek istemiyorum.Acık söyleyeyim,sektörün şu an birkaç eksiği var:

          Birinçisi>,observability tarafı henüz olgunlaşmadI.Bir agend suspend edildiğinde Prometheus metricleri nasıl davranacak? Loki log toplama suspended pod’lardan ne kadar veri kaybedecek? Bu sorular şu an tamamen netleşmiş değil.

          İkinci>,multi-cluster senaryoları bulanık.Bir agend bIr cluster’da suspend edilip başka cluster’da resume olabilir mi? Pratikte çok değerli olurdu(özellikle disaster recovery için)ama roadmap’te henüz göremiyorum.

          ,ekosistem entegrasyonu.ArgoCD.Flux gibi GitOps araçları Sandbx CRD’yi nasıl yönetecek? Tek bi’r Sandbax değişikliği nasıl rollout edilecek? Topluluktá tartışma sürüyor.Kubernetes v1.36 : Silinemeyen Admission Politikaları Dönemiwritmnda bahsettiğim policy yönetimiyle uyum kısmI da hâlâ muallakta.doshe

          1. Önümüzdeki altı ayda ag ent runtime stratejimiz ne olacak?” sorusunu masaya koyun
            <\ol />

            Sıkça Sorulan Sorular

            Agent Sandbox production-ready mi?

            Şunu fark ettim: Kısaca hayır. Hani aslında SIĞ Apps altında hâlâ aktif geliştirme sürüyor. Şu an için PoC, lab ortamı, internal tooling gibi düşük riskli şeylerde deneyin yeter. Bence production’a taşımak için en az 6-9 ay daha beklemek lazım — önce GA olduğunu görelim.

            İşte tam da bu noktada devreye giriyor.

            Mevcut Deployment veya StatefulSet’lerimi değiştirmem gerekecek mi?

            Klasik stateless API’larınız ve veritabanlarınız olduğu gibi kalıyor, yani Sandbox onların yerini almıyor. Sandbox aslında sadece AI agent gibi singleton, stateful, uzun ömürlü workload’lar için düşünülmüş. Mevcut mimarinize bir şeyler ekliyor, değiştirmiyor — bu açıdan rahat olun (ben de ilk duyduğumda şaşırmıştım)

            gVisor mu Kata Containers mı daha iyi?

            Açıkçası duruma göre değişiyor. gVisor genelde daha hızlı; syscall filtreleme yaklaşımıyla çalışıyor. Kata işe mikro VM sayesinde çok daha güçlü izolasyon sağlıyor, ama overhead’i biraz daha fazla — valla güzel iş çıkarmışlar —. Mesela finans gibi yüksek güvenlik gereken yerlerde Kata mantıklı, daha hafif workload’larda gVisor tercih edilebilir. Tecrübeme göre çoğu durumda gVisor ile başlamak yeterli.

            AKS’te Agent Sandbox kullanabilir mıyım?

            Teknik olarak evet. Ama hani AKS’in managed yapısı yüzünden runtime class kurulumu biraz farklı işliyor. Şu an en pratik yol “DaemonSet ile gVisor kurma” yöntemi. Microsoft’un native destek vermesini bekliyoruz — ama açıkçası henüz resmî bir takvim yok ortada.

            Bu konu için hangi sertifikalar/öğrenme yolları öneriyorsunuz?

            CKA (Certified Kubernetes Administrator) bence kesinlikle temel olarak şart. Üstüne bir de CKS (Security Specialist) alırsanız çok değerli oluyor, yani runtime izolasyonu konusunda gerçekten sağlam bir zemin veriyor. Azure tarafından geliyorsanız AZ-104 ve AZ-500 ikilisi gayet iyi bir başlangıç noktası.

            Kaynaklar ve İleri Okuma

            Kubernetes Blog — Running Agents on Kubernetes with Agent Sandbox

            GitHub — kubernetes-sigs/agent-sandbox Repository

            Şahsen, gVisor Resmî Dokümantasyonu

            Garip gelecek ama, Kata Containers Documentation

      Aşkın KILIÇ

      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.

      AZ-305AZ-104AZ-500AZ-400DP-203AI-102

      Bu içerik işinize yaradı mı?

      Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.

      ← Onceki Yazi
      CodeQL 2.25.5 Çıktı: GitHub Actions Taramaları Keskinleşti
      Sonraki Yazi →
      Visual Studio Nisan Güncellemesi: Cloud Agent Devri Başladı

      Yorum Yaz

      E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

      İçindekiler
      ← CodeQL 2.25.5 Çıktı: GitHub Ac...
      Visual Studio Nisan Güncelleme... →