deniz.in

Piyasalar

Hava durumu

Hava durumu yükleniyor

· kaynak dev.to (home feed)

Kong AI Gateway 2.0, birleşik AI güvenliğini GKE, Cloud Run ve Vertex AI'a taşıyor

Kong AI Gateway 2.0; modelleri, agent'leri ve MCP server'ları birinci sınıf gateway varlıkları olarak ele alıyor ve GKE, Cloud Run ile Vertex AI iş yüklerine kimlik doğrulama, token limitleri ve maliyet kontrolü için tek bir yer sunuyor.

Kong AI Gateway 2.0, birleşik AI güvenliğini GKE, Cloud Run ve Vertex AI'a taşıyor

AI-yerel trafik için bir control plane

Kong AI Gateway 2.0, gateway'i AI'ya özgü yapıların etrafında yeniden inşa ediyor: model sağlayıcıları, agent'ler, MCP tool server'ları ve AI tüketicileri, genel HTTP plugin'lerine bağlı ayarlar yerine birinci sınıf control-plane varlıklarına dönüşüyor. Google Cloud topluluk yazarlarından birinin dev.to'daki incelemesine göre amaç, iş yüklerini halihazırda Google Kubernetes Engine ile Cloud Run arasında bölen ve Gemini modellerini Vertex AI üzerinden çağıran ekiplere kimlik doğrulama, gözlemlenebilirlik ve maliyet yönetişimi için tek bir katman sunmak.

Geleneksel gateway'lerin yetersiz kaldığı yer

Yazının temel argümanı, klasik API gateway'lerinin düz bir çizgi üzerindeki istekleri varsaydığı: bir istemci bir upstream API çağırır ve yanıt alır. Agent'li sistemler böyle çalışmıyor. LLM pipeline'ları, MCP server'ları ve otonom agent'ler döngüsel biçimde çalışır, tool çağırır ve diğer agent'lerle iletişim kurar; bu da deterministik bir proxy'nin hiçbir zaman ele almak için tasarlanmadığı trafik desenleri ve risk profilleri üretir.

Üç yetenek açığı öne çıkıyor:

  • Kotaların istek sayısıyla değil, giriş ve çıkış token sayısıyla ölçülmesi gerekiyor; çünkü tek bir prompt, tipik bir REST çağrısından çok daha fazla kaynak tüketebilir.
  • Prompt'ların kendilerinin de model yönlendirmesi ve kimlik bilgisi soyutlamasıyla birlikte runtime'da incelenmesi gerekiyor.
  • Tool keşfi dinamik olarak yönetilmek zorunda; çünkü agent'ler sabit endpoint'ler çağırmak yerine hangi tool'ların var olduğuna runtime'da karar veriyor.

Plugin yerine birinci sınıf varlıklar

Sürüm 2.0, downstream plugin ekleme yaklaşımını özel soyutlamalarla değiştiriyor. Model sağlayıcıları ve modeller, upstream bağlantı havuzlarını, fallback'leri ve kimlik bilgisi yönlendirmesini yöneten ayrıştırılmış backend'ler olarak davranıyor. MCP server'ları, tool sağlayıcılarını temsil eden varlıklar haline geliyor. Agent'ler, agent'ten agent'e trafik için güvenli kanallar elde ediyor. Tüketiciler ve politikalar ise harcama, prompt guardrail'leri ve erişim hakları üzerinde kimlik kapsamlı limitler tanımlıyor.

Yapılandırma, data plane'den ayrı olarak Kong Konnect'te yaşıyor; böylece runtime operasyonları, yapılandırma sistemleri veri akışlarına maruz kalmadan özel ağlar arasında ölçeklenebiliyor.

GKE ve Cloud Run genelinde çalışma

GKE'de data plane, Kong Kubernetes Operator aracılığıyla dağıtılıyor; modeller ve politikalar custom resource olarak yapılandırılıyor. Gateway, upstream kimlik doğrulamasını Workload Identity Federation ile yapıyor, Google Cloud IAM rollerini devralıyor ve statik service account anahtarlarını ortadan kaldırıyor.

Cloud Run hizmetleri ise özel dahili ingress'e kilitli kalıyor. Gelen tüm istemci ve agent istekleri kimlik doğrulama ve loglama için gateway üzerinden yönlendiriliyor; hem GKE hizmetleri hem de Cloud Run endpoint'leri aynı tüketiciye dönük namespace altında yer alıyor — iki yerine tek güvenlik yığını.

Vertex AI entegrasyonu ve model fallback'leri

Her uygulamaya service account anahtarları dağıtmak yerine model tüketimi gateway üzerinden yönlendiriliyor; gateway, Vertex AI'ın standart ve kurumsal endpoint'lerine erişmek için Workload Identity ile OAuth token'ları üretiyor. Fallback zincirleri — örneğin birincil Gemini Ultra modelinin Gemini Flash'e geçmesi — istemci tarafında hiçbir değişiklik yapılmadan gateway'de yapılandırılıyor; ayrıca yönlendirme, dahili ekipleri standart katmanlara yönlendirirken yüksek verimli, düşük gecikmeli kapasiteyi görev açısından kritik uygulamalara ayırabiliyor.

MCP paketleme ve agent'ten agent'e yönetişim

Bir agent'ın düzlerce ayrı tool endpoint'ine bağlantı açması yerine gateway, tool namespace'lerini tek bir endpoint'te topluyor. Ayrıca tool listesi müzakeresinin kendisini de yakalıyor: örneğin bir faturalandırma tool'u için izne sahip olmayan agent, o tool'u keşif yanıtında hiç görmüyor; yazıya göre bu hem yetkisiz erişimi hem de agent'lerin kendilerine hiç verilmemiş yetenekleri kullanma girişimlerini önlüyor.

Mikroservice sınırları boyunca iletişim kuran agent'ler için gateway karşılıklı kimlik doğrulama uyguluyor, yürütme grafiklerini izliyor ve sınırsız özyineleme döngülerini durdurmayı amaçlayan rate-limit politikalarını zorunlu kılıyor.

Neden önemli

Bulut ekipleri nadiren tek bir hesaplama modelinde standartlaşır: stateful orkestrasyon GKE'ye, stateless API'ler Cloud Run'a, çıkarım ise Vertex AI'a düşer. Burada anlatılan mimari, bu runtime kararlarını yönetişimden ayırıyor — kimlik doğrulama, token üzerinden ölçülen maliyet kontrolü, tool izinleri ve agent kimliği, iş yükünün nerede çalıştığına bakılmaksızın tek bir control plane'de yaşıyor. MCP server'ları ve çok agent'li sistemler yayıldıkça, her runtime için ayrı güvenlik yığınları sürdürmek pahalı ve hataya açık hale geliyor.

Bir uyarı: ayrıntılar tek bir topluluk incelemesinden geliyor, bağımsız bir habere değil; bu nedenle platformu değerlendiren ekipler davranışı kendi gereksinimlerine karşı doğrulamalı. Ancak yön net — AI trafiği giderek artan biçimde geleneksel API proxy'lerinin sunmadığı gateway düzeyinde kontrollere ihtiyaç duyuyor.

  • #kong
  • #ai-gateway
  • #google-cloud
  • #gke
  • #vertex-ai
  • #mcp

İlgili yazılar