Kubernetes dünyasında önemli bir dönüm noktasına yaklaşıyoruz. 11 Kasım 2025 tarihinde Kubernetes SIG Network ve Security Response Committee tarafından yapılan resmi duyuruyla, yıllardır Kubernetes ekosisteminin vazgeçilmez bileşenlerinden biri olan Ingress NGINX’in Mart 2026’da emekli edileceği açıklandı. Bu karar, cloud-native dünyasında trafik yönetimi ve güvenlik konusunda yeni bir çağın başlangıcını işaret ediyor.
Ingress NGINX Neden Emekli Ediliyor?
Kubernetes’in ilk dönemlerinde geliştirilen Ingress NGINX, API’nin örnek bir uygulaması olarak hayata geçirildi. Muazzam esnekliği, zengin özellik seti ve herhangi bir bulut sağlayıcısına bağımlı olmaması sayesinde kısa sürede en popüler Ingress controller’larından biri haline geldi. Ancak zamanla bu popülerlik, sürdürülebilirlik açısından ciddi zorluklar yarattı.
Teknik Borç ve Güvenlik Endişeleri
Ingress NGINX’in geniş özellik yelpazesi ve esnekliği, aynı zamanda bakım zorluklarını da beraberinde getirdi. Özellikle “snippets” annotation’ları aracılığıyla geliştiricilere sunulan keyfi NGINX yapılandırma direktifleri ekleme yeteneği, geçmişte yardımcı bir özellik olarak görülürken, günümüzün güvenlik standartlarında ciddi bir zafiyet olarak değerlendiriliyor. Cloud-native yazılımlara yönelik değişen beklentiler, dünün esnekliğini bugünün aşılamaz teknik borcuna dönüştürdü.
Sürdürülebilirlik Krizi
Kullanıcılar arasındaki popülerliğine rağmen, Ingress NGINX her zaman yetersiz bakım kaynağı sorunuyla mücadele etti. Yıllardır proje, yalnızca bir veya iki kişi tarafından, kendi zamanlarında, mesai saatleri dışında ve hafta sonlarında geliştirildi. 2024 yılında maintainer’lar, Ingress NGINX’i sonlandırma ve Gateway API topluluğuyla birlikte yeni bir controller geliştirme planlarını duyurdu. Ne yazık ki bu duyuru bile, projenin bakımına yardım etmek veya InGate geliştirmek için ek ilgi oluşturmadı.
Gateway API: Modern Kubernetes Ağ Yönetiminin Geleceği
Gateway API, Ingress API’nin yerini alacak şekilde tasarlanmış, Kubernetes ekosisteminin resmi projesidir. Layer 4 ve Layer 7 routing’e odaklanan bu yeni API, Ingress’in sınırlamalarını aşmak ve modern bulut-native uygulamaların gereksinimlerini karşılamak üzere geliştirildi.
Rol Odaklı Tasarım
Gateway API, organizasyonlardaki geleneksel rolleri yansıtan bir yaklaşım benimsiyor:
- Infrastructure Provider (Altyapı Sağlayıcısı): GatewayClass kaynaklarını yönetir
- Cluster Operator (Küme Operatörü): Gateway kaynaklarını oluşturur ve politikaları yönetir
- Application Developer (Uygulama Geliştiricisi): HTTPRoute, GRPCRoute gibi routing kurallarını tanımlar
Bu ayrım, Ingress’te tek bir kaynakta toplanan yetkilerin daha güvenli ve yönetilebilir şekilde dağıtılmasını sağlıyor.
Taşınabilirlik ve Standartlaşma
Ingress’in en büyük sorunlarından biri, controller’lar arasında tutarlılık eksikliğiydi. Her vendor kendi annotation’larını kullanıyordu. Gateway API ise, 20’den fazla implementasyonda çalışan standart bir API sunuyor. Bir vendor’dan diğerine geçiş yapmak istediğinizde, yapılandırmalarınızı yeniden yazmak zorunda kalmıyorsunuz – sadece GatewayClass referansını değiştirmeniz yeterli.
İfade Gücü
Gateway API, Ingress’te annotation’larla yapılabilen pek çok özelliği doğrudan API’de destekliyor:
- Header-based routing (başlık tabanlı yönlendirme)
- Traffic splitting ve weighted routing (trafik bölme ve ağırlıklı yönlendirme)
- Request/response manipulation (istek/yanıt manipülasyonu)
- Traffic mirroring (trafik yansıtma)
- Cross-namespace routing (namespace’ler arası yönlendirme)
Genişletilebilirlik
Gateway API, annotation’larla sınırlı kalmak yerine, çeşitli katmanlarda özel kaynakların bağlanmasına izin veren modüler bir yapı sunar. Bu sayede implementasyonlar, core özelliklere ek olarak kendi gelişmiş özelliklerini ekleyebilirler.
Gateway API'nin Teknik Mimarisi
Gateway API, üç ana kaynak türüyle çalışır:
GatewayClass
Gateway
Route Kaynakları (HTTPRoute, GRPCRoute, TCPRoute, vb.)
Ingress'ten Gateway API'ye Geçiş Stratejileri
Mevcut Ingress yapılandırmalarını Gateway API’ye taşımak önemli bir iştir, ancak doğru stratejiyle sorunsuz gerçekleştirilebilir.
3R Stratejisi: Research, Rollout, Repeat
1. Research (Araştırma) Aşaması
Controller Seçimi: Mevcut Ingress controller’ınızın Gateway API desteği var mı? Yoksa yeni bir controller’a mı geçmeniz gerekiyor? Popüler seçenekler:
- NGINX Gateway Fabric (Ingress NGINX kullanıcıları için)
- Istio Gateway API (service mesh yetenekleri için
- Cilium Gateway API (eBPF tabanlı, yüksek performans)
- Contour (Envoy tabanlı, production-ready)
- Traefik (dinamik yapılandırma)
Mapping Analizi: Mevcut Ingress kaynaklarınızı Gateway API kaynaklarına nasıl eşleyeceğinizi planlayın:
- IngressClass → GatewayClass
- Ingress → Gateway + HTTPRoute
- TLS yapılandırmaları → Gateway listener TLS
- Annotation’lar → Native Gateway API fields
2. Rollout (Dağıtım) Aşaması
POC ile Başlayın: Kritik olmayan workload’larla başlayın. Dev ortamında birkaç servis seçip, Ingress yapılandırmalarını Gateway API’ye dönüştürün.
Canary Deployment: Ingress ve Gateway API’yi paralel çalıştırın. Başlangıçta trafiğin %10’unu Gateway API’ye yönlendirin, ardından kademeli olarak artırın.
Her aşamada:
- Routing davranışını doğrulayın
- Performans metrikleri toplayın
- Log ve trace analizleri yapın
- Load testleri gerçekleştirin
3. Repeat (Tekrarlama) Aşaması
Dev ortamında başarılı testlerden sonra, aynı süreci staging ve production ortamlarında tekrarlayın. Yapılandırmalar büyük ölçüde aynı kalacak, sadece isimler ve resource referansları değişecektir.
Otomatik Dönüşüm Araçları
Manuel geçiş karmaşık görünüyorsa, bir diğer alternatif olarak ingress2gateway aracı yardımcı olabilir:
# ingress2gateway kurulumu
go install github.com/kubernetes-sigs/ingress2gateway@latest
# Mevcut Ingress kaynaklarını Gateway API'ye dönüştür
ingress2gateway print --providers ingress-nginx
Bu araç, mevcut Ingress kaynaklarınızı tarayarak otomatik olarak Gateway ve HTTPRoute kaynaklarına dönüştürür. Ancak, sonuçları mutlaka gözden geçirip test edin.
Gelecek ve Ekosistem Evrimi
Gateway API v1.4, Kasım 2025’te yayınlandı ve şu yeni özellikleri getirdi:
- Session Persistence (alpha)
- Backend TLS Policy improvements
- Client Certificate Verification
- Retry Budget (experimental)
Kubernetes ekosistemin Gateway API’ye yönelik ivme artıyor. Service mesh projelerinden (Istio, Linkerd) cloud provider’lara (AWS Gateway API Controller, Google Cloud GKE Gateway) kadar geniş bir destek var.
Öneriler
Ingress NGINX’in emekliye ayrılması, acil bir kriz değil, Kubernetes ekosisteminin doğal evrimidir. Gateway API, modern cloud-native uygulamaların ihtiyaçlarını karşılamak üzere tasarlanmış, daha güvenli, daha esnek ve daha standart bir çözüm sunuyor.
Hemen Başlayın
- Mevcut durumunuzu değerlendirin: Kaç Ingress kaynağınız var? Hangi annotation’ları kullanıyorsunuz?
- Öğrenme yatırımı yapın: Gateway API dokümantasyonunu inceleyin, hands-on lab’ler yapın.
- Küçük başlayın: Bir test workload’ı ile PoC yapın.
- Topluluğa katılın: Kubernetes Slack #sig-network-gateway-api kanalı, GitHub discussions.
- Zaman çizelgesi oluşturun: Mart 2026’dan önce migration planınızı tamamlayın.
Kubernetes altyapınızda bu geçişi sorunsuz gerçekleştirmek, security posture’ınızı güçlendirmek ve gelecekte daha esnek bir traffic management stratejisi oluşturmak için profesyonel destek almayı düşünebilirsiniz.
Kubernetes Gateway API
kurulum, göç ve danışmanlığı
Deneyimli ekibimizle Kubernetes platformlarınızın Gateway API kurulum, göç ve danışmanlık hizmetlerimizle sizlerin yanındayız.
Kubernetes çözümlerinden kurumsal destek almak mı istiyorsunuz?







