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)
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.
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?
İ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ı,
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.
| Özellik | Eski Durum | v1 | v1.5 Durumu | Tipik Kullanım Alanı |
|---|---|---|---|---|
| ListenerSet | Experimental | Standard (Stable) | Multi-tenant Gateway paylaşımı | |
| TLSRoute | Experimental | Standard (Stable) | SNI bazlı TLS yönlendirme | |
| CORS FilterE xperimentalS tandard (Stable)Cross-origin istek yönetimi} |
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ı
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.
3 comments