Gateway API v1.5: Altı Özellik Stable Oldu, Ne Değişiyor?
Kubernetes tarafında ağ yönetimi deyince benim aklıma hep aynı sahne geliyor: önce Ingress ile başlıyorsunuz, bir süre idare ediyor, sonra trafik büyüyünce “hmm, bu iş burada tıkanıyor galiba” diyorsunuz. Ben bunu 2023’te bir e-ticaret müşterisinde birebir yaşadım; neyse, lafı uzatmadan konuya gireyim.
Gateway API v1.5, 27 Şubat 2026’da çıktı ve şimdiye kadarki en büyük sürüm olduğunu söylüyorlar. Altı tane Experimental özellik Stable (Standard) kanala geçti. Bu da şu anlama geliyor: artık production’da “yarın değişir mi acaba” diye bakmadan kullanabiliyorsunuz. Hani o küçük iç sıkıntısı vardı ya, biraz azalıyor.
Release Train Modeli: Trene Binen Gidiyor
İtiraf edeyim, Bu sürümle birlikte Gateway API ekibi release train modeline geçmiş. Açık konuşayım, bana göre teknik detaydan bile daha önemli bir değişiklik bu. Eskiden özellik hazır olana kadar herkes bekliyordu; bazen aylarca, bazen de insanın sabrı taşacak kadar uzun (şaşırtıcı ama gerçek). Şimdi işe feature freeze tarihine yetişen trene biniyor, yetişemeyen bir sonraki seferi bekliyor.
Bu mantık size tanıdık geldiyse normal (bizzat test ettim). Kubernetes’in kendi ritmi de zaten buna yakın gidiyor. SIĞ Release’in yıllardır kullandığı düzeni Gateway API ekibi de almış; güzel tarafı şu ki sadece kod değil, dokümantasyon da hazır olmak zorunda. Yanı “kodu yazdık, dökümanı sonra çıkarırız” dönemi bitmiş gibi dürüyor. İyi olmuş aslında, çünkü kaç kez çalıştığını anlayamadığım bir özelliğin peşinde döküman aradığımı ben de sayamadım.
Ha, bir de Release Manager ve Release Shadow rolleri gelmiş. Flynn (Buoyant) ile Beka Modebadze (Google) bu süreci koordine etmişler ve sonraki sürümde de devam edecekleri söyleniyor. Tutarlılık fena değil.
ListenerSet: Multi-Tenant Yapılarda İşe Yarayan Parça
Bakın şimdi, beni en çok heyecanlandıran kısım burası öldü. Neden mi? Anlatayım.
Bilmem anlatabiliyor muyum, Geçen yıl bir finans kuruluşunda AKS üzerinde multi-tenant bir yapı kuruyorduk. Platform ekibi Gateway’i yönetiyordu, uygulama ekipleri işe kendi listener’larını açmak istiyordu. Eski modelde tüm listener’lar doğrudan Gateway objesine yazılmak zorundaydı. Yanı her yeni servis için platform ekibinin Gateway YAML dosyasına tekrar tekrar dokunması gerekiyordu; 15 farklı ekip aynı kapıya abanıyorsa merge conflict çıkmaması. Mucize olurdu.
ListenerSet tam olarak bu düğümü çözüyor. Listener’ları Gateway’den ayrı tanımlayıp sonra hedef Gateway’e bağlıyorsunuz. Her ekip kendi namespace’inde kendi ListenerSet kaynağını yönetebiliyor; controller da bunları toplayıp tek yerde birleştiriyor.
Nasıl Çalışıyor?
Mantık basit aslında: merkezî altyapı ekibi ortak bir Gateway tanımlıyor. Içine varsayılan HTTP listener koyuyor; sonra farklı ekipler kendi ListenerSet kaynaklarını oluşturup aynı Gateway’e bağlıyorlar (işin püf noktası da burada). Mesela şöyle:
apiVersion: gateway.networking.k8s.io/v1
kind: ListenerSet
metadata:
name: team-alpha-listeners
namespace: team-alpha
spec:
parentRef:
name: shared-gateway
namespace: infra
listeners:
— name: team-alpha-https
hostname: "alpha.example.com"
port: 443
protocol: HTTPS
tls:
certificateRefs:
— name: alpha-cert
namespace: team-alphaBir detay daha var: artık tek bir Gateway’e 64’ten fazla listener ekleyebiliyorsunuz. Büyük deployment’larda bu baya rahatlatıcıydı açıkçası. Ama durun — Gateway objesinin içinde yine en az bir geçerli listener olması gerekiyor. Yanı “boş Gateway açayım, her şeyi ListenerSet halletsin” modeli yok; şimdilik böyle.
Türkiye’deki Kurumsal Yapılar İçin Ne Anlama Geliyor?
Türkiye’deki şirketlerde — özellikle bankacılıkta. Telekomda — DevOps olgunluğu arttıkça platform ekibiyle uygulama ekiplerinin sınırları daha net çiziliyor. Logosoft’ta danışmanlık verdiğim projelerde şunu çok gördüm: çoğu kurum shared infrastructure modeline sıcak bakıyor. Yetki paylaşımı kısmında işler karışıyor; biri “benim alanım”, öbürü “hayır o benim bağımlılığım” derken konu uzuyor da uzuyor (en azından benim deneyimim böyle)
Bir dakika — bununla bitmedi. Bu konuyla ilgili A2A v1 ile.NET’te Çapraz Platform Agent İletişimi yazımıza da göz atmanızı tavsiye ederim.
ListenerSet burada fena olmayan bir çözüm sunuyor diyebilirim. Küçük startup için belki gereksiz kalır ama 5+ ekipli kurumsal yapılarda ciddi rahatlık sağlıyor.
Tam da öyle.
TLSRoute: TCP Üzerinde TLS Yönlendirme Artık Stable
TLSRoute’un yaptığı şey şu: TLS bağlantılarını SNI (Server Name Indication) üzerinden yönlendirmenizi sağlıyor. HTTPRoute’tan farkı ne derseniz, HTTP katmanına çıkmadan TCP seviyesinde TLS passthrough yapabiliyorsunuz. Neden önemli bu? Araya girip terminasyon yapmak zorunda kalmıyorsunuz. Service Bus Batch İşlemede Mesaj Bazlı Settlement Devrimi yazımızda bu konuya da değinmiştik.
Şöyle ki, Bunu nerede kullanıyoruz? Mesela veritabanlarında. Bir müşterimizde PostgreSQL cluster’ını Gateway üzerinden dışarı açmamız gerekmişti ve TLS terminasyonu istemiyorlardı; uçtan uca şifreleme şarttı zaten (en azından benim deneyimim böyle). TLSRoute olmadan bunu düzgün yapmak epey uğraştırıcıydı. Eski düzende TCP proxy kurup SNI routing’i elle ayarlıyorduk (biraz kırılgan, biraz da sıkıcıydı). Şimdi tek YAML ile toparlanabiliyor. SPFx Yol Haritası Nisan 2026: AI Özellikleri ve 1.23 RC yazımızda bu konuya da değinmiştik.
Tabiî küçük bir not düşeyim: TLSRoute desteği implementation’a göre değişebiliyor.
Envoy tabanlı çözümler genelde sorunsuz gidiyor. Başka controller’larda sürpriz çıkabiliyor.
Ben Contour ile denediğimde 2024 başında birkaç edge case’e takılmıştım; sonra düzeldi ama ilk temas pek iç açıcı değildi açıkçası.
Peki neden? Daha fazla bilgi için .NET 10’da API Versiyonlama ve OpenAPI Entegrasyonu: Pratik Rehber yazımıza bakabilirsiniz.
Evet.
CORS Filtresi HTTPRoute’a Geldiğinde Ne Öldü?
CORS dediğimiz şey frontend tarafının meşhur baş ağrısıdır ya hani Cross-Origin Resource Sharing. Backend tarafında da işler çok temiz değildi; annotation’larla uğraşıyorduk, middleware yazıyorduk, proxy config kurcalıyorduk. Gateway API v1
5 ile CORS filtresi doğrudan HTTPRoute içine geliyor.
Daha önce ne yapıyorduk? Ya uygulama kodunun içinde CORS header’larını yönetiyorduk ya da Ingress annotation’larına gömüyorduk.
İkisi de pek iç rahatlatan yöntemler değildi.
Şimdi bunu Gateway seviyesinde tanımlayabilmek iş görüyor doğrusu.
Ama hemen şunu söyleyeyim:
Her şeyi Gateway’e yığmak doğru değil bence;
uygulama katmanında da CORS kontrolü olmalı,
defense in depth dediğimiz şey biraz bunun için var. Daha fazla bilgi için Copilot Chat PR İnceleme: Diff Üzerinde Yapay Zeka Desteği yazımıza bakabilirsiniz.
Peki neden?
CORS’u sadece Gateway’de yönetmek cazip görünebilir ama güvenlik katmanlarını tek noktaya bağlamak riskli.Uygulama seviyesinde de mutlaka kontrol edin.
Sertifika Yönetiminde İki Ayrı Adım
Client Certificate Validation (mTLS)
Doğrusu, Mutual TLS yanı mTLS — sunucunun istemciyi doğruladığı,
istemcinin de sunucuyu doğruladığı yapı. Finans sektöründe,
sağlıkta,
kamu projelerinde bu ihtiyaç neredeyse kaçınılmaz oluyor. Gateway API’de bunun Stable hâle gelmesi demek,
artık mTLS’i Gateway seviyesinde daha güvenli şekilde kurgulayabilirsiniz demek.
Bir bankacılık projesinde —
2024 sonlarıydı sanırım —
mTLS’i Ingress-NGINX üzerinde ayağa kaldırmak için baya uğraşmıştık.
Annotation’lar,
ConfigMap’ler,
custom header’lar…
Gateway API ile bu iş daha temiz görünüyor.
Ama sertifika rotasyonu kısmını yine sizin otomatikleştirmeniz lazım;
bunu sistem gelip sizin yerinize yapmıyor,
orası net.
Peki neden?
Certificate Selection for TLS Origination
Bu özellik biraz niş kalıyor. Ihtiyacı olan için altın değerinde diyebilirim.
Gateway’in backend’e bağlanırken hangi client sertifikasını kullanacağını seçebiliyorsunuz.
Bilhassa de de farklı backend’lere farklı sertifikalarla gitmeniz gereken senaryolarda —
mesela microservice’ler arasında zero-trust mimarisi kurarken —
bu gerçekten kilit hâle geliyor.
— valla güzel iş çıkarmışlar —
ReferenceGrant : Cross-Namespace Güvenliğin Temeli
Küçük bir detay: Durun bir saniye,
önce şunu söylemem lazım:
ReferenceGrant zaten vardı. Experimental durumdaydı.
Şimdi Stable olması önemli çünkü cross-namespace referansların yolu ancak böyle açılıyor.
Doğrusu, Ne işe yarıyor?
Diyelim ki team-alpha namespace’indeki bir HTTPRoute,
infra namespace’indeki bir Secret’a (
TLS sertifikası ) referans vermek istiyor.
Normal şartlarda Kubernetes buna izin vermez;
namespace izolasyonu var sonuçta.
ReferenceGrant ile infra namespace’i “evet,
team-alpha benim şu Secret’ımı kullanabilir” diyor.
Basit gibi dürüyor ama etkisi ciddi.
| Özellik | Eski Durum | v1 | .5 Durumu | Tipik Kullanım Alanı |
|---|---|---|---|---|
| ListernerSet | E xperimental | S tandard (Stable) | M ulti-tenant Gat eway paylaşımı | |
| TLSRouteE xperimentalS tandard (Stable)SNI bazlı TLS yönlendirme | E xperimentalS tandard (Stable)SNI bazlı TLS yönlendirme | S tandard (Stable) | SNI bazlı TLS yönlendirme | |
| E xperimentalS tandard (Stable)C ross-origin istek yönetimi | S tandard (Stable) | C ross-origin istek yönetimi | ||
| Client Certificate Validation | Experimental | Standard (Stable) | mTLS, karşılıklı doğrulama | |
| Certificate Selection | Experimental | Standard (Stable) | Backend’e özel sertifika seçimi | |
| ReferenceGrant | Experimental | Standard (Stable) | Cross-namespace kaynak erişimi |
Kullanırken Nelere Bakmalı?
- B irden fazla ekibin aynı altyapıyı paylaştığı multi-tenant ortamlar
- M TLS zorunluluğu olan regüle sektörler (
finans,
sağlık,
kamu ) - D ox’tan fazla hostname yöneten büyük ölçekli deployment’lar
- P latform ekibi ile uygulama ekibi arasında net sorumluluk ayrımı gereken yapılar
- C ross-namespace kaynak paylaşımının güvenli şekilde yapılması gereken durumlar
Maliyet açısından bakarsak:
Gateway API’nın kendisi ücretsiz,
çünkü açık kaynak.
Ama kullanacağınız implementation’a göre (
Envoy Gateway,
Contour,
Istio,
Kong )
iş değişiyor.AKS üzerinde Envoy Gateway kullanırsanız lisans ücreti ödemezsiniz,
ama compute tüketimi artabilir;
bunu FinOps planınıza dahil etmekte fayda var.
Sıkça Sorulan Sorular
Gateway API v1.5 ile Ingress tamamen kalkıyor mu?
Eh, Hayır, Ingress hâlâ destekleniyor. Yakın zamanda kaldırılması gibi bir plan da yok açıkçası. Ama yeni bir şey kuruyorsanız, bence Gateway API’ye geçmek daha mantıklı. Mevcut Ingress yapılarınız sorunsuz çalışmaya devam ediyor.
Çok konuştum, örnekle göstereyim.
ListenerSet kullanmak için mevcut Gateway’ımı yeniden oluşturmam gerekiyor mu?
Gerek yok. Var olan Gateway’inize ListenerSet ekleyebilirsiniz — yanı her şeyi sıfırdan yapmak zorunda değilsiniz. Tek şart şu: Gateway’in en az bir geçerli listener’ı olması lazım. ListenerSet’ler mevcut yapının üstüne oturuyor, hani tamamen ayrı bir şey değil.
Hangi Gateway API implementation’ını seçmeliyim?
Bu biraz ortama göre değişiyor. AKS kullanıyorsanız Envoy Gateway güzel bir başlangıç noktası. Zaten Istio’daysanız onun Gateway API desteği de epey olgunlaşmış durumda. Kong veya Traefik tercih edenler için de destek var. Ama tecrübeme göre en kritik nokta şu: kullandığınız sürümün v1.5 Standard özelliklerini gerçekten desteklediğinden emin olun.
mTLS’i Gateway seviyesinde mi yoksa uygulama seviyesinde mi yapmalıyım?
Şunu fark ettim: İkisini de yapın. Yanı mesela Gateway seviyesinde client certificate validation kurarsınız, uygulama tarafında da ek kontroller eklersiniz. Defense in depth prensibi bu — tek bir katmana güvenmek pek sağlıklı değil bence.
Gateway API v1.5 hangi Kubernetes sürümlerini destekliyor?
Bi saniye — Resmî olarak Kubernetes 1.27 ve üzeri destekleniyor. Ama açıkçası en iyi deneyim için 1.30+ kullanmanızı tavsiye ederim — özellikle CEL validation özelliklerinden tam anlamıyla yararlanmak istiyorsanız.
Kaynaklar ve İleri Okuma
Gateway API v1.5 Resmî Kubernetes Blog Yazısı
İçeriği paylaş:
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder