Google, gVisor sandbox’ını ve iki agent projesini CNCF’e bağışlıyor

Google, gVisor sandbox’ını Agent Substrate ve OpenRL projeleriyle birlikte Cloud Native Computing Foundation’a (CNCF) bağışlıyor. CNCF, gVisor başvurusunu Eylül sonunda kabul etti ve projenin onboarding süreci geçen hafta başladı. Aynı duyuruyla Agent Substrate 1.0 yayımlandı ve Google Kubernetes Engine (GKE) üzerinde genel kullanıma açıldı.

Kısaca gVisor nedir

gVisor, container’lar ile host işletim sistemi arasına ek bir izolasyon katmanı koyan açık kaynak bir sandbox runtime’ıdır. Uygulamanın system call’larını user space’te çalışan kendi kernel’inde karşılar ve kodun host kernel’ine doğrudan erişmesini engeller. Güvenilmeyen kodu veya yapay zekâ agent’larının ürettiği kodu çalıştıran platformlarda kullanılır. Kubernetes’te runsc adlı runtime ve RuntimeClass ile devreye alınır. Benzer amaçla kullanılan bir alternatif Firecracker’dır.

gVisor sandbox’ında karar yetkisi el değiştiriyor

Güvenilmeyen kodu container içinde çalıştırıyorsanız bu haber doğrudan sizi ilgilendiriyor. GVisor bugüne kadar fiilen Google’ın projesiydi; merge yetkisi ve test altyapısı şirketin içindeydi.

Perot ve Chen’in Ekim planına göre geliştirme ve test altyapısı Google dışına taşınacak. Harici maintainer’lar da merge yetkisi alacak. Yeni yönetim modelinde kararları tek bir şirket alamayacak.

Geçişin pratik bir yan etkisi var: release’lerin üretildiği CI ve dağıtım kanalları değişebilir. GVisor’ı node image’larına gömüyorsanız sürümü sabitleyin. Binary’yi hangi adresten çektiğinizi de not edin, proje taşındığında kaynağı bilinçli olarak güncelleyin.

Agent kodu hâlâ runc ile mi çalışıyor

Temmuzda OpenAI’daki bir siber güvenlik değerlendirmesinde modeller kısıtlı ortamdan çıkıp Hugging Face’in production altyapısına sızdı. OpenAI’ın son güvenlik raporu da Linux kernel açıklarının hasarını sınırlamak için gVisor ve Firecracker gibi sandbox’ları öne çıkarıyor.

Standart container’lar host kernel’ini paylaşır. GVisor ise uygulamanın system call’larını user space’te çalışan kendi kernel’inde karşılıyor; kod host kernel’ine doğrudan ulaşmıyor. Anthropic, Claude’un ürettiği kodu web platformunda bu yolla çalıştırıyor.

LLM çıktısını, kullanıcı script’ini veya CI’da dışarıdan gelen kodu çalıştıran iş yükleriniz varsa önce envanter çıkarın. Hangi Pod’un hangi runtime ile çalıştığını görmek için:

kubectl get runtimeclass
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name} {.spec.runtimeClassName}{"\n"}{end}'

RuntimeClassName alanı boş olan Pod’lar varsayılan runtime ile çalışıyor. Node’lara runsc kurduktan sonra gVisor için bir RuntimeClass tanımlayıp yalnızca güvenilmeyen kod çalıştıran iş yüklerini ona yönlendirebilirsiniz:

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: gvisor
handler: runsc

I/O yoğun iş yüklerinde performans farkı

Haberde en az konuşulan ama sahayı en çok etkileyecek kısım kernel değişiklikleri. Google ve gVisor kullanan bazı şirketler, özellikle I/O yoğun uygulamalarda performansı artıran kendi kernel değişikliklerini tutuyor. Bu yamalar upstream’e girmedi. Standart bir Linux dağıtımında gVisor bu yüzden aynı hızda çalışmayabilir.

Bradstock, upstream maintainer’ların proje tek bir vendor’a aitken bu değişiklikleri almadığını söylüyor. LWN’nin 2022 haberi ise en az bir öneriye güvenlik ve tasarım gerekçesiyle itiraz edildiğini gösteriyor. CNCF çatısı yönetim itirazını zayıflatabilir, teknik itirazları ortadan kaldırmaz. Bu yamaların yakında mainline kernel’e gireceğini varsaymayın.

Bu yüzden gVisor’a geçmeden önce kendi iş yükünüzle ölçüm yapın. Paket kurulumu, build adımları ve yoğun dosya okuyan agent görevleri runc ile gVisor arasında karşılaştırılmaya değer. Fark kabul edilemezse gVisor’ı yalnızca dış kaynaklı kod çalıştıran node pool’una sınırlayın.

Agent Substrate 1.0 ve OpenRL için acele yok

Agent Substrate, Kubernetes’in üzerine ek bir runtime katmanı koyuyor. Boşta bekleyen agent’ı askıya alıp gerektiğinde geri getiriyor ve bunu Pod’u her seferinde silip yeniden oluşturmadan yapıyor. Agent’ın kalıcı state’i ile onu çalıştıran compute ayrılıyor; izolasyon seçeneklerinden biri gVisor.

Çok sayıda uzun ömürlü agent’ı Pod başına çalıştırıyor ve boşta kalan kaynak için para ödüyorsanız proje tam bu soruna yöneliyor. 1.0 sürümü şu an GKE’de genel kullanımda. GKE dışındaki cluster’lar için kurulum yolunu kaynak anlatmıyor; CNCF altındaki dokümantasyon netleşene kadar production planı yapmayın.

OpenRL, kendi Kubernetes altyapınızda reinforcement learning ile model fine-tuning’i koordine ediyor ve Agent Substrate ile entegre çalışıyor. Proje Haziranda duyuruldu. Şimdilik deney ortamında tutun.

Sıralama şöyle olsun: önce güvenilmeyen kod çalıştıran iş yüklerinizi bulun ve gVisor’ı ölçerek devreye alın. Agent Substrate’i GKE kullanıyorsanız bir test namespace’inde deneyin, OpenRL’yi ise CNCF altında ilk sürümleri çıkana kadar izleme listesine koyun.