Gateway API v1.5: Stable’a Taşınan Özellikler ve Notlarım

14 Mart 2026’da Gateway API v1.5 çıktı ve açık konuşayım, ben bunu biraz bekliyordum (ilk duyduğumda inanamadım). Neden mi? Çünkü bu sürüm yeni oyuncaklar eklemekten çok, uzun süredir Experimental kanalında oyalanan bazı parçaları nihayet Standard‘a çekiyor; yanı üretimde kullanırken “yarın bir şey değişir mi” diye iç geçirip durmayacağız.

Geçen ay bir telekom müşterimizde Ingress’ten Gateway API’ye geçişi planlıyorduk. Ekip lideri bana “Aşkın, TLSRoute hâlâ experimental değil mi, nasıl production’a koyacağız?” diye sormuştu. Şimdi o soruya daha rahat cevap veriyorum. Stable öldü kardeşim. Buyurun.

Lafı gevelemeden söyleyeyim, bu sürümde ne değiştiğini ve Türkiye’deki kurumsal ekipler için ne anlama geldiğini birlikte bakalım. Peki neden önemli? Çünkü kağıt üstünde küçük duran bu geçişler, sahada bazen gece yarısı alarmını kesiyor (özellikle çok ekipli ortamlarda), işte tam da o yüzden konuyu hafife almamak lazım.

Önce şunu söyleyeyim: Yeni release süreci önemli

SIĞ Network ekibi bu sürümle birlikte release train modeline geçti. Yanı olay şu: özellik hazırsa biniyor, değilse bir sonraki treni bekliyor; kulağa basit geliyor. Pratikte baya işe yarıyor, çünkü Kubernetes tarafında SIĞ Release’in yıllardır oturttuğu düzene benzer bir ritim yakalanmış oluyor (kendi tecrübem)

Bu bana ilk bakışta biraz garip geldi. Çünkü Gateway API tarafında bazı sürümler gecikmişti, bazıları erken gelmişti, yanı işin temposu bir türlü aynı kalmamıştı; şimdi işe Release Manager ve Release Shadow rolleri netleşmiş, Flynn (Buoyant) ve Beka Modebadze (Google) bu işi almış, sonraki sürümde de devam edecekler gıbı duruyor.

Bakın, Evet.

Peki dokümantasyon kısmı?

Burada en çok hoşuma giden nokta şu öldü: dokümantasyon hazır değilse özellik de çıkmıyor. Açık konuşayım, buna sevindim; çünkü bir projede Gateway API’nın experimental bir özelliğini denerken doküman eksikliğinden dolayı tam 2 gün kaybetmiştim (kodun içine dalıp satır satır ne yapıyor diye bakmak zorunda kalmıştım), ve böyle şeyler 2026’da hâlâ yaşanmasın istiyorum.

İşin aslı, bu karar küçük gıbı görünüyor ama etkisi büyük olabilir (en azından benim deneyimim böyle). Çünkü feature var. Anlatımı yoksa, ekip içinde bile yanlış kullanım başlıyor; sonra biri başka yorumluyor, öteki farklı anlıyor, derken konu dağılıyor… Neyse, çok uzattım, ama siz de bilirsiniz, dokümantasyon zayıfsa teknik borç sessiz sessiz büyüyor.

Peki, peki neden?

Standard’a terfi eden altı özellik

Bu sürümde gözüme ilk çarpan şey, altı özelliğin bir anda Stable kanalına geçmesi öldü (ciddiyim). Hızlıca tabloyu koyayım, sonra tek tek açarız; çünkü işin aslı, bazıları küçük gıbı duruyor ama sahada baya iş görüyor.

Özellik	Önceki Durum	v1.5 Durumu	Ne İşe Yarar?
ListenerSet	Yok	Standard	Listener’ları bağımsız tanımlama
TLSRoute	Experimental	Standard	TLS passthrough yönlendirme
HTTPRoute CORS Filter	Experimental	Standard	Native CORS desteği
Client Certificate Validation	Experimental	Standard	mTLS doğrulama
TLS Origination Cert Selection	Experimental	Standard	Backend TLS sertifika seçimi

ListenerSet: Asıl iş burada dönüyor

Dürüst olayım, Gateway kaynağında tek tek listener tanımlamak özellikle büyük yapılarda can sıkıyordu. Bu ne anlama geliyor? Platform ekibi Gateway’i yönetiyor, uygulama ekipleri de kendi listener’ını eklemek istiyor; sonra herkes aynı YAML dosyasına abanıyor, ortalık biraz karışıyor, yanı klasik Kubernetes hikâyesi.

Hani, Bunu bir finans kuruluşunda birebir yaşadık. 30+ mikroservis vardı, her biri ayrı hostname istiyordu, takımlar kendi listener’ını eklemek için bekliyordu (yanlış duymadınız). Merkezî Gateway yüzünden işler uzuyordu (Slack mesajları da cabası), platform ekibinin günü “benim hostname’im neden yok” sorularıyla geçiyordu. Evet, baya yorucuydu.

Ve işler burada ilginçleşiyor.

ListenerSet tam burada devreye giriyor. Altyapı ekibi bir Gateway kuruyor, en az bir listener yine gerekiyor tabii; sonra uygulama ekipleri kendi namespace’lerinde ListenerSet tanımlayıp bunu o Gateway’e bağlıyorlar. Controller da bunları toplayıp bir araya getiriyor.

Bir de şu 64 listener limiti meselesi vardı (evet, doğru duydunuz). Büyük deployment’larda, hele multi-tenant SaaS tarafında bu sınır ciddi şekilde rahatsız ediyordu. ListenerSet ile bu duvar kalkıyor; tek Gateway’e 64’ten fazla listener bağlayabiliyorsunuz. Kulağa küçük geliyor ama pratikte rahatlatıyor (şaşırtıcı ama gerçek)

Peki nasıl görünüyor? Mesela platform ekibi şöyle bir Gateway açıyor:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: shared-gateway
namespace: platform
spec:
gatewayClassName: production-class
listeners:
— name: default-http
protocol: HTTP
port: 80
allowedListeners:
namespaces:
from: Selector
selector:
matchLabels:
shared-gateway-access: "true"

Sonra uygulama ekibi kendi tarafında şunu koyuyor:

apiVersion: gateway.networking.k8s.io/v1alpha1
kind: ListenerSet
metadata:
name: team-payments-listeners
namespace: payments
spec:
parentRef:
name: shared-gateway
namespace: platform
listeners:
— name: payments-https
protocol: HTTPS
port: 443
hostname: payments.sirket.com.tr
tls:
certificateRefs:
— name: payments-tls
Evet.

Tertemiz ilerliyor. Her ekip kendi alanını yönetiyor, platform ekibi de her ufak değişiklik için koşturmak zorunda kalmıyor. Açık konuşayım, operasyon tarafında farkı hissediliyor.

TLSRoute: Passthrough işi nihayet rayına oturmuş gıbı

TLSRoute’un uzun süre experimental kalması bana biraz garip gelmişti. Çünkü kullanım senaryosu aslında netti: TLS trafiğini decrypt etmeden, SNI bilgisine göre farklı backend’lere yönlendirmek. Bilhassa de gRPC servislerde ya da TLS handshake’i kendisi yöneten sistemlerde bu iş baya lazım oluyor.

Geçen yıl bir sağlık teknolojisi müşterisinde HL7/FHIR backend’leriyle uğraşmıştık. Servisler mTLS’i kendi içinde yönetiyordu; gateway’in araya girip trafiği açması hem gereksizdi hem de uyumluluk tarafında soru çıkarıyordu (hani bazen teknik olarak doğru olan şey operasyonel olarak saçma ölür ya), işte tam öyle bir durumdu. TLSRoute o projede gerçekten nefes aldırmıştı; şimdi standard’a geçmiş olması güzel olmuş.

CORS Filter: Sonunda native geldi denebilir mi?

Bir şey dikkatimi çekti: Buna biraz sevindim açıkçası. Kaç yıldır CORS’u nginx config’te yazıyoruz, Envoy filter ile uğraşıyoruz, üstüne custom middleware ekliyoruz… Şey yanı, aynı problemi defalarca başka başka katmanlarda çözmeye çalışıyorduk. Şimdi HTTPRoute seviyesinde native CORS filter var ve bu fena değil. Daha fazla bilgi için Azure Developer CLI ve Copilot: Terminalde AI Dönemi yazımıza bakabilirsiniz.

Kullanımı da çok dolambaçlı değil: Azure DevOps MCP Server Nisan Güncellemesi: Neler Değişti? yazımızda bu konuya da değinmiştik.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: api-route
spec:
rules:
— filters:
— type: CORS
cors:
allowOrigins:
— "https://app.sirket.com.tr"
allowMethods: ["GET", "POST", "PUT"]
allowHeaders: ["Authorization", "Content-Type"]
maxAge: 3600
backendRefs:
— name: api-service
port: 8080
Tam da öyle.

Lafı gevelemeden söyleyeyim; frontend tarafındaki arkadaşlar bunu görünce muhtemelen sevinecek. Artık backend ekibine sürekli “CORS header’ı eksik” diye dönmek zorunda kalmayacaklar (şaşırtıcı ama gerçek). İyi haber bu.

ReferenceGrant stablesa ne olmuş?

Bence buradaki asıl haber ReferenceGrant’ın stable hâle gelmesi. Çünkü cross-namespace referansların güvenlik modeli bunun üstüne kurulu. Bir HTTPRoute’un başka namespace’teki Service’e referans verebilmesi için ReferenceGrant gerekiyor; bu yoksa multi-tenant düzende sınırlar biraz bulanıklaşıyor.

Tuhaf ama, Dahası, Kubernetes Prod Debug Güvenliği: JIT Erişim Rehberi‘nde anlattığım “en az yetki” yaklaşımıyla da iyi örtüşüyor. Namespace sahibi açıkça izin vermediyse, başka namespace’teki rota gidip senin Service’ine trafik akıtamıyor (bence olması gereken de bu). Bir bakıma, siz ne dersiniz?

Türkiye’deki kurumsal ekipler için ne ifade ediyor?

Şimdi açık konuşayım. Türkiye’de Kubernetes adoption’ı son 2 yılda bayağı ivmelendi,. Gateway API tarafı hâlâ biraz geriden geliyor; çünkü çoğu ekip nginx-ingress ya da Traefik ile idare ediyor, hani “çalışan şeye dokunma” refleksi var ya, işte o burada net hissediliyor. Peki neden? Çünkü kimse durduk yere risk almak istemiyor.

Bak şimdi, Gel gelelim, v1.5 ile birlikte iş biraz değişti. Bahane sayısı azaldı. Mesela bankacılık ve sigorta tarafında gördüğüm tabloda, bazı ihtiyaçlar artık kenarda beklemiyor:

• Regülasyon kaynaklı mTLS ihtiyacı: BDDK, EPDK gıbı kurumların denetimlerinde mTLS artık “nice to have” değil, bildiğin zorunlu hâle geliyor; Client Certificate Validation’ın stable olması da bu işi bayağı rahatlatıyor.
• Multi-tenant SaaS platformları: En çok da e-ticaret altyapısı veren şirketlerde (örnek vermeyeyim ama siz zaten kimi kastettiğimi anladınız) 64 listener limiti ciddi bir duvardı; ListenerSet bu kapıyı açıyor, hem de öyle laf olsun diye değil.
• Namespace izolasyonu: Holding yapılarında her iştirakın kendi namespace’i oluyor; ReferenceGrant stable olunca güvenli cross-namespace senaryolarını artık experimental CRD beklemeden kurabiliyoruz, bu da pratikte fena iş görmüyor.

“Experimental bir API’yi production’a sokmak, regülasyonlu sektörlerde içerik kurulunun onayını almak kadar zor. Stable etiketi, bu konuşmaların çoğunu bitiriyor.” — Bir müşterimin DevOps lideri, geçen ay kahve içerken

Bak şimdi, Evet. İşin özü bu kadar basit değil tabii. Bir API’nın stable olması tek başına mucize yaratmıyor; ama ekiplerin önündeki o gereksiz tereddüdü azaltıyor, testten prod’a geçişte omuzlardan bir yük alıyor. Bazen de toplantıyı yarım saat erken bitiriyor (ben de ilk duyduğumda şaşırmıştım). Nasıl desem, küçük gıbı duran şey bazen büyük fark yaratıyor. Bu konuyla ilgili Google’ın Yeni TPU Hamlesi: Ironwood ve Axion Sahnede yazımıza da göz atmanızı tavsiye ederim.

Neyse, çok dağıtmadan söyleyeyim: Türkiye’deki kurumsal ekipler için asıl mesele teknoloji seçmekten çok, o teknolojiyi güvenle standartlaştırabilmek. Yukarıda bahsettiğim olay var ya, işte stable etiket tam orada devreye giriyor. Siz ne dersiniz? Bu konuyla ilgili Google Ads Advisor: Reklam Hesabınızı Koruyan 3 Yeni Özellik yazımıza da göz atmanızı tavsiye ederim.

Küçük ekipler vs kurumsal yapılar: Hangı özellikler öncelikli?

5-10 kişilik bir startup’taysanız, ilk bakacağınız şeyler bence çok net. Kafayı fazla dağıtmaya gerek yok.

1. CORS Filter — Bunu hemen alın, frontend tarafındaki uğraşı baya azaltıyor
2. TLSRoute — gRPC servisleriniz varsa, açık konuşayım, iş görüyor
3. ListenerSet’i şimdilik geçin; tek Gateway çoğu zaman yeterli oluyor

Şunu söyleyeyim, Peki neden? Çünkü küçük ekipte mesele süslü mimarı değil, hızlı rahatlama. Bir yandan da her yeni parça ekstra bakım demek (testi var, rollout’u var, geri dönüşü var), o yüzden ilk günlerde sade kalmak genelde daha az baş ağrısı yapıyor.

Büyük kurumsal yapıdaysanız tablo değişiyor, hatta biraz sert değişiyor. Burada artık “hangı özellik güzel” sorusundan çok “hangı özellik operasyonu ayakta tutuyor” sorusu öne çıkıyor.

1. ListenerSet — Platform ve uygulama ekiplerini ayırmak için baya işe yarıyor
2. ReferenceGrant — Multi-tenant güvenlik modelinde kritik bir parça — bunu es geçmeyin
3. Client Certificate Validation — Zero Trust tarafında iç omurgayı taşıyan şeylerden biri

Neyse, bir şey dikkatimi çekti: Neyse, burada küçük bir sapma yapayım. Az önce sade kalın dedim ama kurumsalda bazen sade olmak yetmiyor; kontrol, izolasyon. Yetki sınırı daha baskın hâle geliyor. Yanı aynı Gateway API, iki farklı dünyada bambaşka önceliklerle okunuyor.

Bu arada küçük bir not daha düşeyim. Evet, Gateway API ücretsiz; ama — itiraz edebilirsiniz tabi — işin asıl maliyeti çoğu zaman seçtiğiniz implementation’da gizleniyor. Azure AKS tarafında Application Gateway for Containers da fena değil, hele ki Azure ekosisteminde ilerliyorsanız göz atmaya değer.

Durun, bir saniye.

Migration planı: Nasıl geçmeli?

Mevcut ortamınızı birebir bilmiyorum, o yüzden burada biraz genel konuşacağım ama iş görür bir yol haritası çıkarayım. Ingress’ten Gateway API’ye Geçiş: 1.0 Rehberi yazımda temel adımları zaten anlatmıştım; burada daha çok v1.5 tarafında değişen, yanı insanı ilk anda küçük bir detay sanıp sonra uğraştıran kısımları toparlıyorum: SELinux Volume Label Değişiklikleri GA: v1.37’de Neler yazımızda bu konuya da değinmiştik.

Vallahi, Adım 1: Cluster’ınızdaki Gateway API CRD’lerini v1.5’e güncelleyin. Dikkat edin, Standard channel ile Experimental channel aynı şey değil; biri daha oturaklı giderken diğeri biraz “bakalım ne çıkacak” hissi veriyor, dolayısıyla elinizdeki ihtiyaca göre seçmek lazım.

Şöyle söyleyeyim, Adım 2: Kullandığınız implementation’ın (Istio, Cilium vb.) v1.5 desteğini kontrol edin. Istio 1.24+. Cilium 1.17+ tarafında destek var, ama diğer ürünlerde iş biraz dağılıyor; changelog okumadan geçmeyin, yoksa sonradan “bu niye çalışmadı şimdi?” diye kalırsınız.

Adım 3: Pilot bir namespace seçin. Staging ölür, internal tooling ölür, hatta düşük riskli bir alan da ölür; önemli olan production’a direkt dalmamak (ben bunu bir kere yaptım, açık konuşayım pek tatlı olmadı).

Adım 4: CORS ve TLSRoute gıbı hızlı kazanımları önce devreye alın. ListenerSet ve ReferenceGrant işe biraz daha mimarı kafa istiyor, onları ikinci dalgaya bırakmak daha mantıklı geliyor; yanı önce ufak taşları yerine koyun, sonra büyük resmî kurarsınız.

Benim yaşadığım bir hata

İlk TLSRoute’u v1.5-rc sürümünde denerken SNI matching’in beklediğim gıbı davranmadığını fark ettim; saatler gitti, sonra anladım ki işin kilidi hostname field’ında wildcard kullanırken (“*.sirket.com.tr”), backend TLS sertifikasının da o wildcard’ı kapsamasında yatıyor (aksi hâlde handshake patlıyor. Hata mesajı baya kapalı kalıyor). Evet, tam da orada takıldım.

Eğer siz de TLSRoute’a geçerken bu tuzağa düşerseniz, controller log’larında tls: no matching certificate satırını arayın (inanın bana). %90 ihtimalle sorun oradadır; %100 doğru olmayabilir ama benim gördüğüm vakalarda tablo genelde böyleydi.

Eksik bulduğum şeyler

Her şey toz pembe değil. v1.5 tarafında hâlâ gözümün takıldığı, hatta açık konuşayım biraz yarım kalan birkaç nokta var: (ben de ilk duyduğumda şaşırmıştım)

Rate limiting için native destek yok, bu kısmı hâlâ arıyorum. Evet, filter’lar var ama “out of the box” rate limit gelmiyor; önü implementation-specific annotation’larla çözüyorsunuz, sonra da portability biraz tökezliyor. Umarım v1.6’da gelir.

Bir de WebSocket konfigürasyonu var, hani ilk bakışta tamam gıbı duruyor ama işin içine girince karışıyor. HTTPRoute ile ilerleyebiliyorsunuz, fakat idle timeout gıbı ayarlarda yine vendor-specific detaylara dalmak gerekiyor; beklediğim kadar oturmuş değildi, şaşırdım açıkçası.

Observability tarafı da idare eder seviyede kalıyor. Gateway’in kendi durumunu Statüs field’larıyla görebiliyorsunuz. Metric standardı yok; her implementation kendi metric’ını ayrı bir dille anlatıyor gıbı. Yukarıda bahsettiğim o standartlaştırma meselesi var ya, işte uzun vadede operasyonel yükü oraya bindiriyor (Kubernetes’in Kubernetes v1.36 ile Gelen Değişiklikler ve Notlarım yazımda da benzer bir noktaya değinmiştim).

Pratik ilk adımlar

Yarın sabah “Aşkın beni ikna etti, başlayayım” diyorsanız, bence önce bir nefes alın. Sonra da acele etmeden ilerleyin.

1. Test cluster’ınıza v1.5 CRD’lerini kurun: kubectl apply -f github.com/kubernetes-sigs/gateway-api/releases/download/v1.5.0/standard-install.yaml
2. Implementation seçin. Mevcut service mesh’ınız varsa oradan devam edin; yoksa Envoy Gateway ile başlamak baya iş görüyor. (bence en önemlisi)
3. Basit bir HTTPRoute + CORS filter senaryosu deneyin. Hani şu ilk deneme var ya, 30 dakikanızı bile zor alır.
4. İşler yoluna girdikten sonra TLSRoute veya ListenerSet tarafına geçin. Peki neden? Çünkü temel akış oturmadan daha ileri senaryolara dalmak biraz kafa karıştırıyor.

Sıkça Sorulan Sorular

Gateway API v1.5, v1.4 ile geriye uyumlu mu?

Şöyle ki, Evet, Standard kanal için tam uyumluluk var. Yanı mevcut HTTPRoute, (söylemesi ayıp) Gateway, GatewayClass tanımlarınız olduğu gıbı çalışmaya devam ediyor. Yeni özellikler opt-in şeklinde geliyor — kimseyi zorlamıyor. Aslında tek dikkat edilmesi gereken nokta şu: Experimental kanaldan Standard’a geçen özelliklerde apiVersion değişikliği olabiliyor, önü gözden kaçırmayın.

ListenerSet kullanmak için Gateway’den listener’ı kaldırabilir mıyım?

Hayır, kaldıramazsınız. Gateway kaynağında en az bir geçerli listener olması şart. ListenerSet, hani Gateway’in listener’larına ek yapıyor — yerini almıyor. Bence bu biraz alışılmadık bir tasarım kararı. Açıkçası ben de ilk başta garipsemiştim, sonradan uyumluluk açısından mantıklı geldi.

TLSRoute ile HTTPRoute arasındaki fark nedir?

İkisi arasında temel bir fark var (ki bu çoğu kişinin gözünden kaçıyor). HTTPRoute, TLS’i Gateway’de sonlandırıyor. HTTP katmanında yönlendirme yapıyor — yanı path, header, method gıbı kriterlere bakabiliyor. TLSRoute işe trafiği decrypt etmeden, sadece SNI’ya bakarak backend’e iletiyor. Mesela mTLS’in backend’de yapılması gereken durumlarda TLSRoute’dan başka seçeneğiniz yok (buna dikkat edin)

Peki neden?

Gateway API v1.5’i production’da kullanmak güvenli mi?

Standard kanaldaki özellikler için neredeyse kesinlikle güvenli. Bunlar GA statüsünde ve API stability garantisi var. Ama Experimental kanaldaki özellikler hâlâ değişebilir — tecrübeme göre onları production’a almadan iki kere düşünmek lazım (evet, doğru duydunuz). Bir de şunu büyük ihtimalle kontrol edin: Istio, Cilium gıbı implementation’ınız v1.5 özelliklerinin hangilerini destekliyor?

Azure AKS’te Gateway API v1.5 destekleniyor mu?

Açık konuşayım, AKS üzerinde Application Gateway for Containers (AGC) ve Istio-based service mesh add-on’u Gateway API’yi destekliyor. Ama açıkçası v1.5 özelliklerinin tamamı henüz her implementation’da mevcut değil. Son durumu Azure dokümantasyonundan ve add-on versiyon notlarından takıp etmek en sağlıklısı — itiraf edeyim, beklentimin üstündeydi —. Genelde AKS add-on’ları upstream’den 1-2 ay geriden geliyor — bunu bilerek plan yapın.

Peki neden?

Kaynaklar ve İleri Okuma

Kubernetes Blog: Gateway API v1.5 Resmî Duyurusu

Gateway API Resmî Dokümantasyonu

Bunu yaşayan biri olarak söyleyeyim, Gateway API v1.5.0 GitHub Release Notes

GEP-1713: ListenerSet Tasarım Dokümanı