Gateway API v1.5: Altı Özellik Stable Oldu, Ne Değişiyor?

Kubernetes tarafında ağ yönetimi deyince benim kafamda hep aynı sahne dönüyor: önce Ingress ile başlıyorsunuz, bir süre iş görüyor, sonra trafik büyüyünce “hmm, burada bir yerde tıkanıyoruz galiba” diyorsunuz (ilk duyduğumda inanamadım). Ben bunu 2023’te bir e-ticaret müşterisinde birebir yaşadım; neyse, lafı uzatmadan konuya gireyim (şaşırtıcı ama gerçek)

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 şunu anlatıyor: 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 — ki bu tartışılır — 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 sürüyordu (şaşırtıcı. Gerçek). Şimdi işin mantığı şu: 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. SIG Release’in yıllardır kullandığı düzeni Gateway API — itiraz edebilirsiniz tabi — ekibi de almış; güzel tarafı şu ki sadece kod değil, dokümantasyon da hazır olmak zorunda. Yani “kodu yazdık, dökümanı sonra çıkarırız” dönemi bitmiş gibi duruyor. İ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.

Bunu biraz açayım.

Dürüst olmak gerekirse, Ha, bir de Release Manager ve Release Shadow rolleri gelmiş (ki bu çoğu kişinin gözünden kaçıyor). Flynn (Buoyant) ile Beka Modebadze (Google) bu süreci koordine etmişler. 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ı oldu. Neden mi? Anlatayım.

Geçen yıl bir finans kuruluşunda AKS üzerinde multi-tenant bir yapı kuruyorduk (inanın bana). Platform ekibi Gateway’i yönetiyordu, uygulama ekipleri ise kendi listener’larını açmak istiyordu. Eski modelde tüm listener’lar doğrudan Gateway objesine yazılmak zorundaydı; yani 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.

Vallahi, 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. İç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-alpha

Bir 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. Yani “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 ve 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 (evet, doğru duydunuz)

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.

Size bir şey söyleyeyim, 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 (ben de ilk duyduğumda şaşırmıştım). 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.

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ı.
Daha açık söyleyeyim, peki neden?
Daha fazla bilgi için .NET 10’da API Versiyonlama ve OpenAPI Entegrasyonu: Pratik Rehber yazımıza bakabilirsiniz.

İtiraf edeyim, Evet.

CORS Filtresi HTTPRoute’a Geldiğinde Ne Oluyor?

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.
Kısacası, 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 yani mTLS — sunucunun istemciyi doğruladığı, istemcinin de sunucuyu doğruladığı yapı.Bu tarz ihtiyaçlar finans sektöründe,
sağlıkta,
kamu projelerinde neredeyse kaçınılmaz oluyor.Gateway API’de bunun Stable hâle gelmesi demek,
artık mTLS’i Gateway seviyesinde daha rahat kurgulayabilirsiniz demek.

B ir 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.

Küçük bir detay: Peki neden?

C ertificate Selection for TLS Origination

Yani, B u özellik biraz niş kalıyor.S 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 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

Bakın, küçük bir detay:
Durun bir saniye,
önce şunu söylemem lazım:
ReferenceGrant zaten vardı.Experimentaldurumdaydı.
Şimdi Stable olması önemli çünkü cross-namespace referansların yolu. Böyle açılıyor.

D oğ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 duruyor. Etkisi ciddi.

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

  — bunu es geçmeyin

• 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?

Hayır, Ingress hâlâ destekleniyor. Yakın zamanda kaldırılacak diye bir plan da yok açıkçası (inanın bana). Ama yeni bir şey kuruyorsanız bence Gateway API’ye geçmek çok daha mantıklı. Mevcut Ingress yapılarınız sorunsuz çalışmaya devam ediyor zaten.

Lafı uzatmadan bir örnekle göstereyim.

ListenerSet kullanmak için mevcut Gateway’ımı yeniden oluşturmam gerekiyor mu?

Gerek yok. Var olan Gateway’inize ListenerSet ekleyebilirsiniz — yani her şeyi sıfırdan kurmak 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?

Bak şimdi, 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 — bunu atlamayın.

Bir dakika — bununla bitmedi.

mTLS’i Gateway seviyesinde mi yoksa uygulama seviyesinde mi yapmalıyım?

Aslında ikisini de yapın. Mesela Gateway seviyesinde client certificate validation kurarsınız, uygulama tarafında da ek kontroller eklersiniz (ciddiyim). 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?

Resmî olarak Kubernetes 1.27 ve üzeri destekleniyor (evet, doğru duydunuz). Ama açıkçası en iyi deneyim için 1.30+ kullanmanızı öneririm — özellikle CEL validation özelliklerinden tam anlamıyla yararlanmak istiyorsanız bu önemli.

Kaynaklar ve İleri Okuma

Gateway API v1.5 Resmî Kubernetes Blog Yazısı

Gateway API Resmî Dokümantasyonu (şaşırtıcı ama gerçek)

Gateway API v1.5.1 GitHub Release Sayfası

Aşkın KILIÇYazar

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.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102

İlgili Yazılar

CodeQL Autofix Raporları Artık Daha Gerçekçi31 Mar 2026

Java OpenJDK Nisan 2026 Güncellemesi: Bellek, Güvenlik ve Sürprizler5 May 2026

VSTest Newtonsoft.Json Bağımlılığını Atıyor: Ne Değişiyor?2 May 2026

Kanban ve Sprint Panolarında Alan Savaşı: Ekran Kurtarma9 Mar 2026