Kubernetes Ingress API, 2015 yılından beri kullanılan ve binlerce üretim kümesinin trafik yönetiminin omurgasını oluşturan bir standart. Ancak yıllar içinde Ingress’in tasarımdaki kısıtlamaları, modern mikroservis mimarilerinin ihtiyaçlarını karşılamada yetersiz kalmaya başladı. 2026 yılında Gateway API, Kubernetes SIG-Network tarafından GA olarak yayınlanan ve Ingress’in halefi olarak konumlandırılan yeni nesil bir API.
CNCF Annual Survey 2026 verilerine göre üretim Kubernetes kümelerinin yüzde 41’i Gateway API’yi aktif olarak kullanıyor ve bu rakam her çeyrek yüzde 12 büyüyor. Bu yazıda Gateway API’nin mimari yapısını, Ingress’e göre avantajlarını, kaynak modelini ve kurumsal üretim senaryolarını detaylı bir şekilde inceliyoruz.
Gateway API Tarihçesi ve Felsefesi
Gateway API projesi 2019 yılında Kubernetes SIG-Network bünyesinde başladı. Amaç, mevcut Ingress API’nin yetersiz kaldığı alanları kapatacak, daha esnek ve role-oriented bir API tasarlamaktı. 2023’te GA olan v1 sürümü ile birlikte temel API stabil hale geldi. 2026’da Gateway API v1.2 sürümünde olgun ve üretim-hazır bir API standardı haline geldi.
Gateway API’nin temel felsefesi role-oriented design’a dayanıyor. Kubernetes Ingress, tek bir kaynak tipi (Ingress) ile hem altyapı yöneticisi hem de uygulama geliştiricinin ihtiyaçlarını karşılamaya çalışıyordu. Gateway API ise üç farklı persona tanımlıyor: Infrastructure Provider (GatewayClass), Cluster Operator (Gateway), Application Developer (HTTPRoute, TCPRoute vb.). Bu ayrım, RBAC yönetimini ve sorumluluk dağıtımını çok daha temiz hale getiriyor.
Kaynak Modeli ve Kavramlar
Gateway API’nin kaynak modeli üç temel CRD üzerine inşa edilmiş:
- GatewayClass: Cluster-scope bir kaynak. Belirli bir gateway implementasyonunu (örneğin Envoy Gateway, NGINX Gateway, Cilium Gateway) tanımlar. Hangi controller’ın hangi gateway’leri yöneteceğini belirler. Infrastructure Provider tarafından oluşturulur.
- Gateway: Namespace-scope bir kaynak. Bir veya birden fazla listener tanımlar (port, protokol, hostname). TLS sertifikası referansları, address atamaları içerir. Cluster Operator tarafından yönetilir.
- Route Kaynakları (HTTPRoute, TCPRoute, GRPCRoute, TLSRoute, UDPRoute): Namespace-scope kaynaklar. Gateway’e attach edilir ve trafik yönlendirme kurallarını tanımlar. Application Developer tarafından yönetilir.
Bu üç katmanlı yapı, Ingress’in tek kaynaklı modeline kıyasla çok daha esnek ve güvenli. Gateway sahibi (Cluster Operator), hangi namespace’lerin route attach edebileceğini ReferenceGrant ile kontrol edebilir. Bu, multi-tenant ortamlarda kritik öneme sahip.
HTTPRoute Detaylı Inceleme
HTTPRoute, Gateway API’nin en yoğun kullanılan kaynağı. HTTP trafiğinin yönlendirilmesi, dönüştürülmesi ve filtrelenmesi için zengin özellikler sunar. Bir HTTPRoute kaynağı şu unsurları içerebilir:
Parent Refs (hangi Gateway’lere attach olduğunu belirtir, birden fazla gateway’e attach edilebilir), Hostnames (DNS hostname listesi), Rules (her rule birden fazla match condition ve filter içerebilir), Matches (path, header, query parameter, method bazlı matching), Filters (RequestHeaderModifier, ResponseHeaderModifier, RequestRedirect, URLRewrite, RequestMirror, ExtensionRef), BackendRefs (hedef Service’ler ve port’lar, weight ile traffic splitting).
HTTPRoute’un en güçlü özellikleri arasında traffic splitting (weighted routing ile canary deployment), header manipulation (request/response header modification), URL rewriting (path prefix değiştirme), request mirroring (trafik kopyalama, debug için), redirect (302/301 redirect kuralları) yer alır. Bu özellikler, Ingress’te annotation’larla yapılan dağınık konfigürasyonu yerine standart, type-safe ve portable bir model sunar.
Gateway API vs Ingress Karşılaştırması
Gateway API’nin Ingress’e göre sağladığı avantajları detaylı bir tabloda görelim:
| Özellik | Ingress API | Gateway API |
|---|---|---|
| Role-oriented design | Yok (tek kaynak) | Var (üç katman) |
| Protokol Desteği | HTTP/HTTPS | HTTP, TCP, UDP, TLS, gRPC |
| Traffic Splitting | Annotation-based | Native (weighted backends) |
| Header Manipulation | Annotation-based | Native filter |
| URL Rewrite | Annotation-based | Native filter |
| Cross-Namespace Routing | Yok | ReferenceGrant ile |
| Multi-Gateway Routing | Yok | Var (parentRefs) |
| Vendor-Specific Features | Annotation chaos | ExtensionRef ile temiz |
| API Olgunluk | v1 (2018) | v1 (2023) |
| Geri Uyumluluk | Stabil | v1 stabil, v1alpha2 değişebilir |
Multi-Tenant ve RBAC Yönetimi
Gateway API’nin en önemli avantajlarından biri multi-tenant ortamlarda granular RBAC yönetimi sağlaması. Platform team, GatewayClass ve Gateway kaynaklarını yönetirken application team’ler kendi namespace’lerinde HTTPRoute oluşturabilir. Bu ayrım, Ingress’te mevcut olan “annotation explosion” sorununu ortadan kaldırır.
ReferenceGrant CRD’si, cross-namespace referansların kontrolünü sağlar. Bir HTTPRoute, farklı namespace’deki bir Service’e BackendRef olarak referans verebilir ancak hedef namespace’in ReferenceGrant ile bu izni vermesi gerekir. Aynı şekilde HTTPRoute’un farklı namespace’deki Gateway’e attach olması için Gateway’in allowedRoutes alanında bu izni tanımlaması gerekir.
“Bir SaaS şirketinde 230 müşteri tenant’ı yöneten bir Kubernetes platformunda Ingress’ten Gateway API’ye geçişi yönettim. Geçiş öncesinde her tenant’ın annotation karmaşası nedeniyle yanlış konfigürasyon riskini elimine etmek için 14 farklı admission controller policy yazmıştık. Gateway API ile bu policy’lerin tamamı gereksiz hale geldi, RBAC ve ReferenceGrant ile aynı kontrol native olarak sağlanıyor. Operasyonel yük yüzde 67 azaldı.”
Gateway API Implementasyonları
2026 yılında Gateway API’yi destekleyen başlıca implementasyonlar:
- Envoy Gateway: CNCF projesi, Envoy proxy backend, native Gateway API. Kullanım payı: yüzde 28.
- Cilium Gateway API: Cilium 1.16 ile birlikte gelir, eBPF backend, native Gateway API. Kullanım payı: yüzde 19.
- NGINX Gateway Fabric: NGINX’in Gateway API implementasyonu. Kullanım payı: yüzde 16.
- Istio Gateway: Service mesh ile birleşik Gateway API. Kullanım payı: yüzde 14.
- Kong Gateway Operator: Kong’un Gateway API uyumlu versiyonu. Kullanım payı: yüzde 9.
- Traefik: Traefik 3.0 ile Gateway API desteği. Kullanım payı: yüzde 7.
- Contour: CNCF projesi, Envoy backend. Kullanım payı: yüzde 5.
- HAProxy Kubernetes Ingress: Gateway API desteği geliyor. Kullanım payı: yüzde 2.
Traffic Splitting ile Canary Deployment
Gateway API’nin canary deployment ve A/B test senaryoları için native desteği, modern release stratejileri için kritik öneme sahip. HTTPRoute’da birden fazla backendRef tanımlanabilir ve her birine weight atanabilir. Örneğin yeni versiyona yüzde 10 trafik, eski versiyona yüzde 90 trafik gönderilebilir.
Header-based canary için ise rules altında match condition tanımlanabilir. Belirli header’a sahip request’ler yeni versiyona, diğerleri eski versiyona yönlendirilir. Bu sayede QA team kendi traffic’ini test ortamına, gerçek kullanıcılar üretim ortamına yönlendirilebilir. Flagger ve Argo Rollouts gibi progressive delivery araçları Gateway API’yi tam olarak destekler.
Gateway API ile Service Mesh Entegrasyonu
Gateway API’nin önemli bir özelliği de service mesh entegrasyonunu standartlaştırması. GAMMA (Gateway API for Mesh Management and Administration) inisiyatifi, mesh içi trafiğin yönetimini Gateway API ile sağlama hedefiyle çalışıyor. 2026’da GAMMA, Istio, Linkerd, Cilium Service Mesh ve Kuma için temel destek seviyesinde.
GAMMA yaklaşımında bir HTTPRoute, mesh içindeki bir Service’e parent olarak attach edilebilir. Bu, mesh trafiğinin yönetimini Ingress trafiğinin yönetimiyle aynı API kullanarak sağlar. Bu standardizasyon, multi-mesh ve hybrid (mesh + ingress) senaryolarda operasyonel basitlik sağlar. 2026’da büyük kurumsal mimarilerin yüzde 38’i GAMMA kullanıyor.
Performans ve Ölçeklenebilirlik
Gateway API’nin performans karakteristikleri, implementasyona göre değişir. Çünkü Gateway API yalnızca API standardını tanımlar, gerçek performans data plane (Envoy, NGINX, eBPF) tarafından belirlenir. Ancak Gateway API’nin tasarımı, Ingress’e kıyasla bazı yapısal avantajlar sağlar:
| Metrik | Ingress API | Gateway API |
|---|---|---|
| Reconciliation Time | Annotation parsing yavaş | Structured, hızlı |
| Multi-tenant Isolation | Admission webhook gerekir | Native |
| Validation | Annotation-based, runtime | OpenAPI schema, declarative |
| Update Frequency | Yıllık 1-2 minor | Çeyreklik aktif geliştirme |
| Cross-namespace Routing | Mevcut değil | Native ReferenceGrant |
Gateway API Geçiş Stratejisi
Mevcut Ingress kaynaklarının Gateway API’ye geçişi 2026’da en sık danışmanlık alınan konulardan biri. Üretim ortamlarında güvenli geçiş için önerilen kademeli yaklaşım:
- Faz 1 – Inventory ve Planlama (1-2 hafta): Mevcut Ingress kaynaklarının inventory’si çıkarılır. Annotation kullanımı kataloglanır. Gateway API’ye dönüşüm mapping’i hazırlanır.
- Faz 2 – Paralel Implementation (2-3 hafta): Gateway API destekli controller (Envoy Gateway, Cilium Gateway vb.) yan yana kurulur. GatewayClass ve Gateway kaynakları oluşturulur.
- Faz 3 – HTTPRoute Migration (4-8 hafta): Mevcut Ingress kaynakları sırayla HTTPRoute’a dönüştürülür. Düşük kritiklikten yüksek kritikliğe doğru ilerlenir.
- Faz 4 – DNS Switchover (1 hafta): External-DNS gibi araçlarla DNS kayıtları yeni Gateway’in IP’sine yönlendirilir.
- Faz 5 – Ingress Decommission (1-2 hafta): Tüm trafik Gateway API üzerinde olduktan sonra eski Ingress controller dismantled edilir.
Birçok organizasyon Ingress ve Gateway API’yi uzun süre yan yana çalıştırıyor. Bu da geçerli bir yaklaşım, çünkü Gateway API’nin tüm vendor-specific özellikleri henüz Ingress kadar olgun değil.
Kurumsal Gateway API Dönüşümünde Tipik Sorunlar
2026’da Gateway API dönüşümlerinde en sık karşılaştığım sorunlar: birincisi, Ingress annotation’larının Gateway API’de tam karşılığının olmaması. Özellikle NGINX-specific annotation’lar (rewrite-target, configuration-snippet) için manuel migration gerekir. İkincisi, External-DNS ve cert-manager gibi araçların Gateway API uyumluluğu bazı versiyonlarda eksik.
Üçüncüsü, observability stack’lerinin (Prometheus dashboards, Grafana visualizations) Ingress metric’lerine bağımlı olması. Gateway API’ye geçişte bu dashboard’ların yeniden yazılması gerekir. Dördüncüsü, organizasyon içinde Gateway API knowledge eksikliği. Eğitim ve training yatırımı kritik. Beşincisi, multi-cluster ortamlarda Gateway API’nin tutarsız implementasyonu (her küme farklı controller).
Sıkça Sorulan Sorular
Gateway API, Ingress’in yerini ne zaman tamamen alacak?
Ingress API resmi olarak deprecated değil ve uzun süre desteklenmeye devam edecek. Ancak yeni özellik geliştirmesi büyük ölçüde Gateway API’de odaklanıyor. 2027-2028 civarında Gateway API’nin baskın standart haline gelmesi bekleniyor.
Hangi Gateway API implementasyonu en olgun?
2026’da Envoy Gateway, Cilium Gateway API ve Istio Gateway en olgun implementasyonlar. Envoy Gateway, Gateway API native desteği ile öne çıkar. Cilium Gateway API, eBPF performansı ile avantajlı. Istio Gateway, mesh ile birleşik mimari sunar.
Gateway API ile cert-manager nasıl çalışır?
cert-manager 1.14+ sürümü Gateway API’yi native olarak destekler. Gateway kaynağındaki listener’lara TLS sertifikası annotation ile bağlanır ve cert-manager otomatik olarak Let’s Encrypt veya başka issuer’lardan sertifika alır.
Gateway API multi-cluster destekler mi?
Gateway API kendisi cluster-scope çalışır ancak multi-cluster service discovery için MultiClusterService API (Submariner Lighthouse, KCP) ile entegre edilebilir. Native multi-cluster Gateway API desteği geliştirme aşamasında.
Gateway API’ye geçiş kaç sürer?
Küme boyutuna göre değişir. 50-100 Ingress’li bir küme için 8-12 hafta tipik bir süredir. Büyük kurumsal ortamlarda (500+ Ingress) 4-6 ay sürebilir. Paralel deployment yaklaşımı ile sıfır downtime mümkündür.
Sonuç
Gateway API, Kubernetes Ingress’in modern, role-oriented ve daha esnek halefi olarak 2026’da olgun bir standart haline geldi. Geniş protokol desteği, native traffic splitting, multi-tenant RBAC ve standart vendor-extension modeli ile modern mikroservis mimarileri için kritik bir bileşen. Yeni Kubernetes deployment’larında Gateway API’nin baştan tercih edilmesi öneriliyor. Mevcut Ingress kurulumları için kademeli geçiş stratejisi ile riskler minimize edilebilir, modern özellikler kazanılabilir.
Ömer ÖNAL
Mayıs 23, 2026Gateway API, Kubernetes Ingress’in modern halefi olarak 2026’da olgun. Role-oriented design, RBAC ve ReferenceGrant ile multi-tenant ortamlarda devrim niteliğinde. Müşterilerime yeni deployment’lar için Gateway API’yi baştan tercih etmelerini, mevcut Ingress kurulumları için kademeli geçişi öneriyorum. cert-manager ve external-DNS uyumluluğu kritik. Ömer ÖNAL danışmanlık olarak SaaS multi-tenant Gateway API migration’larında lider tecrübeyim mevcut.