KubeCon 2026’da NGINX: MCP trafiği, inference ve Ingress-NGINX

NGINX ve F5, 9-12 Kasım’da Salt Lake City’de yapılacak KubeCon + CloudNativeCon North America 2026’da AI trafiği, MCP ve NGINX Gateway Fabric odaklı bir panel, bir konuşma ve bir canlı demo düzenleyecek. Ekip 100 numaralı standda salıdan perşembeye lightning talk’lar yapacak. Standda NGINX Ingress Controller 5.7.0, NGINX Gateway Fabric 2.8.0 ve emekliye ayrılan Ingress-NGINX projesinden geçiş konuşulacak.

NGINX Gateway Fabric nedir, ne işe yarar?

NGINX Gateway Fabric, Kubernetes Gateway API’sinin NGINX’i data plane olarak kullanan açık kaynak bir implementasyonudur. Cluster’a giren HTTP ve diğer trafiği Gateway, HTTPRoute gibi Gateway API kaynaklarıyla yönetmek için kullanılır. Ingress API yerine Gateway API’ye geçen platform ekipleri tercih eder. Alternatifleri arasında Envoy Gateway, Istio ve Kong gibi diğer Gateway API implementasyonları sayılabilir.

Model Context Protocol nedir, ne işe yarar?

Model Context Protocol (MCP), yapay zekâ agent’larının ve LLM uygulamalarının harici araçlara, veri kaynaklarına ve servislere standart bir biçimde bağlanması için geliştirilmiş açık bir protokoldür. Mesajlaşma JSON-RPC üzerine kurulur. Agent’ın dosya okuma, API çağırma ya da veritabanı sorgulama gibi işleri araç çağrısı olarak yapmasını standartlaştırır.

Etkinlik duyurusundan çıkan teknik gündem

Bu bir etkinlik duyurusu. Ama oturum başlıkları, Kubernetes üzerinde AI iş yükü işleten platform ekiplerinin önündeki üç somut sorunu gösteriyor. Birincisi GPU arkasındaki modellere giden trafiğin yönetimi. İkincisi MCP üzerinden araç çağıran agent’ların görünürlüğü. Üçüncüsü Ingress-NGINX’ten çıkış.

Üçü de aynı katmanda çözülüyor: servislerin önündeki gateway. Konferansa gitmeseniz de bu başlıklar kendi cluster’ınız için hazır bir kontrol listesi.

MCP trafiğinde HTTP 200 araç hatalarını gizliyor

Duyurudaki en işe yarar teknik ayrıntı bu. Gateway her MCP çağrısını aynı biçimde görüyor: /mcp yoluna giden bir JSON-RPC POST. Araç başarısız olsa bile yanıt çoğu zaman HTTP 200 dönüyor.

Pratikteki sonuçları:

• Access log’lardaki 5xx oranına bağlı alarmlar ve SLO’lar araç hatalarını hiç görmez.
• Bütün araçlar tek endpoint’te toplandığı için path bazlı rate limiting (hız sınırlama) araçları birbirinden ayıramaz. Pahalı tek bir aracı sınırlamak isterken hepsini sınırlarsınız.
• Hangi aracın kaç kez çağrıldığını ancak istek gövdesine bakarak çıkarabilirsiniz.

NGINX ekibinin demosu, NGINX Open Source’u MCP sunucularının önüne koyup araç bazında metrik, authentication ve rate limit eklemeyi hedefliyor. HTTP 200 içinde saklanan araç hataları Grafana’da gösterilecek. Yapılandırma ayrıntıları duyuruda yok. Şimdilik yapılacak iş belli: MCP sunucularınızın hata bilgisini JSON-RPC yanıt gövdesinde döndürüp döndürmediğini kontrol edin ve izlemeyi status code yerine bu alana göre kurun.

Inference katmanında NGINX Gateway Fabric ve policy as code

KyvernoCon konuşması GPU destekli modellerdeki yönetişim açığını anlatıyor. Modele gitmemesi gereken trafik gidiyor, tenant izolasyonu sessizce bozuluyor, failover policy’yi atlıyor. Kimin hangi GPU’yu kullandığı da fatura gelene kadar bilinmiyor. Konuşmacılara göre açık, AI trafiğini yönlendiren Gateway API ve Inference Extension kaynaklarında.

NGINX Gateway Fabric, Gateway API Inference Extension’ı 2.2.0’dan beri destekliyor. InferencePool ve InferenceObjective kaynaklarıyla inference (çıkarım) trafiği yönlendiriyorsanız ilk soru şu: hangi namespace’ler bu kaynakları oluşturabiliyor ve bir tenant başka bir tenant’ın modeline route yazabiliyor mu? Bunu admission aşamasında bir policy engine ile kurala bağlamak, hatalı tanımı deploy anında durdurur.

Konuşmanın altını çizdiği nokta, admission policy’nin tek başına yetmemesi. Öneri, admission kurallarını runtime controller’larla birlikte kullanmak. Desenlerin herhangi bir Gateway API implementasyonu ve policy engine ile çalıştığı belirtiliyor. Yani NGINX kullanmayan ekipler için de geçerli.

Ingress-NGINX’ten çıkışa envanterle başlayın

Duyuru Ingress-NGINX’i emekliye ayrılmış proje olarak anıyor ve standda iki ayrı lightning talk bu geçişe ayrılmış. Hâlâ Ingress-NGINX çalıştıran cluster’larınız varsa ilk adım envanter:

kubectl get ingressclass
kubectl get pods -A | grep -i ingress-nginx
kubectl get ingress -A -o yaml | grep nginx.ingress.kubernetes.io

Son satır asıl yükü gösterir. nginx.ingress.kubernetes.io önekli annotation’lar Ingress-NGINX’e özgü. Başka bir controller’a taşırken her birinin karşılığını tek tek bulmanız gerekiyor. Annotation sayısı az olan servislerden başlamak geçişi küçük parçalara böler.

Karar noktası, Ingress API’de kalıp başka bir controller’a geçmek ile Gateway API’ye taşınmak arasında. Inference Extension, Gateway API’nin bir eklentisi. Yakın zamanda cluster’da model servis etme planınız varsa Gateway API’ye geçiş, AI trafiği için ikinci bir taşımayı gereksiz kılar.

Salt Lake City’ye gitmeyecekler için

Breakout oturumlarının kayıtları etkinlikten sonra CNCF YouTube kanalına yükleniyor. Stand lightning talk’larının kaydedileceğine dair bir bilgi yok. NGINX Gateway Fabric’te Inference Extension’ı denemek için dokümantasyondaki “Gateway API Inference Extension” sayfası, konuşmadan bağımsız bir başlangıç noktası.