Kubernetes’te AI Agent Sandbox: Pratik Rehber
Geçen ay bir finans müşterimizde ilginç bir toplantı öldü. Ekip, LLM tabanlı birden fazla ajan çalıştırmak istiyordu — her biri farklı görevler yapan, birbirleriyle konuşan, kod üreten ve çalıştıran ajanlar. İlk refleksleri ne öldü? Her ajan için bir StatefulSet tanımla, yanına bir headless Service koy, bir de PersistentVolumeClaim bağla. Sonuç? 15 ajan için 45 ayrı Kubernetes manifesti. Yönetilemez bir karmaşa.
İşte tam da burada SIĞ Apps altında geliştirilen Agent Sandbox projesi devreye giriyor (en azından benim deneyimim böyle). Bakın, proje daha olgunlaşma yolunda ama çözmeye çalıştığı dert baya gerçek (bu beni çok şaşırttı). Ben bunu 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, biter. Kubernetes’in Deployment, ReplicaSet gibi soyutlamaları tam da bu dünya için iyi oturuyor. Ama AI ajanları… 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ı sız de ben de anında bilemiyoruz. Çoğu zaman boşta dürüyor, sonra bir anda iş yükleniyor; yanı klasik request-response mantığından ziyade, daha çok bir “dijital çalışma masası” gibi düşünmek lazım.
İ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 öldü biliyor musunuz? İşte, her ajan için ayrı kaynak tanımı, güvenlik politikası, ağ izolasyonu… 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.
Bi saniye — Mesela ReplicaSet’i alın; çoklu kopya çalıştırmak için tasarlanmış. Ama burada tekil çalışan bir ajandan söz ediyoruz. StatefulSet başvurabilirsiniz, evet; ama sırf 1’lık StatefulSet tanımlamak biraz tuhaf dürüyor. Ü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?
Peki ne var içinde? 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; altında iş gören birkaç önemli parça var.
Güvenlik İzolasyonu
En kritik mesele bu zaten. Bir AI ajanı kod üretiyor ve çalıştırıyor; o kodun ne yapacağını önceden kestirmek zor oluyor. Sandbox tarafı gVisor veya Kata Containers gibi runtime’ları doğal biçimde destekliyor. Yanı 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 yanı.
Yaşam Döngüsü Yönetimi
Bence en hoş taraf burası. Bir ajanı “suspend” edebiliyorsunuz — yanı pod kapanıyor ama durum korunuyor. Bu ne anlama geliyor? 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.
Düşünün: 100 tane ajanınız var ama 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 bu konuya da değinmiştik.
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: 443Bence, Bö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.
Burada, 15 ajan için düz hesapla yine manifest sayısı artar tabii ama en azından yapı dağılmıyor.
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 işe henüz az yerde var.
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. Araç kullanan bir şey istiyorlar.
Sonra da doğal olarak soruyorlar : bunu nereye koyacağız?
Yanı, Büyük bankalar. 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?
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.
| Senaryo | Agen Sandbox Uygun mu? | Alternatif |
|---|---|---|
| Kurum içi kullanım — 50+ ajan, multi-tenant | ✅ Kesinlikle | – |
| Orta ölçek — basit mi diyelim, aslında orta karar ; 5-20 ajan, tek takım | ✅ Faydalı ama şart değil |
| Status quo :
|
İçeriği paylaş:
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.
0 comments