Gateway API v1.6: TCPRoute ve UDPRoute Standard Oldu
Kubernetes SIG Network topluluğu, Gateway API’nin v1.6.0 sürümünü 30 Haziran’da yayımladı. Sürüm, Gateway API’yi HTTP ve TLS gibi 7. katman protokollerinin ötesine taşıyor: Ham TCP ve UDP yönlendirmesi artık üretim seviyesinde kararlı, deneysel API yüzeyi ise ayrı bir grup altında netleştirildi. Yazıda v1.6 ile gelen iki temel değişiklik ve pratik kullanım örnekleri ele alınıyor.
Öne çıkan değişiklikler
Sürümün iki ana başlığı şöyle özetlenebilir:
- TCPRoute ve UDPRoute Standard oldu: Ham L4 TCP/UDP yönlendirmesi
v1API sürümüyle GA kararlılığına ulaştı. - Deneysel API grubu ayrıldı: Deneysel kaynaklar artık
gateway.networking.x-k8s.iogrubunda veXöneki ile yaşıyor; deneysel ile standart arasındaki sınır böylece API grubu düzeyinde belirginleşiyor.
TCPRoute ve UDPRoute Standard kanala geçti
Gateway API bugüne kadar yalnızca HTTP ve TLS trafiği için kararlı bir yönlendirme modeli sunuyordu. TCP veya UDP üzerinden ham protokol konuşan iş yükleri, yani veritabanları, DNS, VoIP, oyun sunucuları, IoT telemetrisi, bir Gateway’e taşınabilir biçimde bağlanmak için ya düz bir Kubernetes Service’e ya da Gateway denetleyicileri arasında taşınmayan uygulamaya özgü CRD’lere düşmek zorundaydı.
TCPRoute ve UDPRoute bu boşluğu kapatıyor, L7 farkındalığı gerektirmeden yalnızca protokol ve port temelinde arka uçlara yönlendirme yapıyor. Bu sürümle birlikte her ikisi de Experimental kanaldan Standard kanala terfi etti ve v1 API sürümüne taşındı. Her iki kaynağın v1alpha2 sürümü v1.6 itibarıyla kullanımdan kaldırıldı olarak işaretlendi; ileriki bir sürümde tamamen kaldırılacak.
TCPRoute nasıl çalışıyor?
Öncelikle bir Gateway’in, TCPRoute eklenmesine izin veren bir listener’a sahip olması gerekiyor:
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: example-gateway
spec:
gatewayClassName: example-gateway-class
listeners:
- name: foo
protocol: TCP
port: 12345
allowedRoutes:
kinds:
- kind: TCPRouteArdından TCPRoute bu listener’a bağlanır ve trafiği bir arka uca iletir:
apiVersion: gateway.networking.k8s.io/v1
kind: TCPRoute
metadata:
name: tcp-app
spec:
parentRefs:
- name: example-gateway
sectionName: foo
rules:
- backendRefs:
- name: my-foo-service
port: 6000Gateway’in 12345 portuna gelen trafik, my-foo-service servisinin uç noktalarına 6000 portu üzerinden proxy’lenir. parentRefs içinde sectionName ve port belirtilmezse route, tek bir listener yerine Gateway üzerindeki tüm TCP listener’lara bağlanır.
UDPRoute örneği
UDPRoute aynı deseni izler; yalnızca listener protokolü ve route türü değişir:
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: example-gateway
spec:
gatewayClassName: example-gateway-class
listeners:
- name: foo
protocol: UDP
port: 12345
allowedRoutes:
kinds:
- kind: UDPRoute
---
apiVersion: gateway.networking.k8s.io/v1
kind: UDPRoute
metadata:
name: udp-app
spec:
parentRefs:
- name: example-gateway
sectionName: foo
rules:
- backendRefs:
- name: my-foo-service
port: 6000XBackend: Deneysel kanalda yeni bir arka uç modeli
v1.6 ile birlikte gelen XBackend, Service ve diğer arka uç türleri için Gateway API içinde genel amaçlı bir “decorator” niteliği taşıyan yeni bir kaynak. Service kaynağı kararlı ve esnek olmasına rağmen bu esneklik, Gateway API’nin çözmek zorunda kaldığı çok sayıda sınır durum yaratıyor; kararlılık ise Service’e yeni kavramlar eklemeyi neredeyse imkansız kılıyor.
XBackend, üstteki EndpointSelector KEP’inin fikirlerine dayanıyor; arka uç uygulamayı hedeflemeye devam ediyor ama Service ile ele alınması zor veya riskli olan senaryolara topluluğun eklemeler yapmasına imkan tanıyan Gateway API’ye özgü bir nesne sunuyor.
XBackend’in ilk sürümü ExternalHostname hedeflerini destekliyor. Bu tür hedefler, “confused deputy” saldırıları riski nedeniyle Gateway API’de Service üzerinden desteklenmiyordu. XBackend’de bu destek Extended/Optional bir özellik olarak sunuluyor; implementasyonlar ve kullanıcılar güvenlik dengelerini anladıktan sonra bu özelliğe opt-in yapabiliyor. Yetenek özellikle egress senaryolarında, küme içinde barındırılan agentic iş yüklerinde sıkça karşılaşılan senaryolarda kullanışlı; topluluk bu yönde Gateways for Egress ile ilgili GEP çalışmalarını sürdürüyor.
Uyarı: XBackend API’si deneyseldir ve davranışı değişebilir; üretimde kullanıma hazır olduğu varsayılmamalıdır.
Bir bulut AI API’sine egress yapmak için ExternalName tipinde bir arka ucun kullanıldığı Gateway örneği aşağıda görülebilir:
# Gelen bağlantılar için Gateway seviyesindeki TLS geçerli olmaya devam eder
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
spec:
listeners:
- name: https
protocol: HTTPS
tls:
certificateRefs:
- name: gateway-cert
---
# Dış hedef için Backend kaynağı
apiVersion: gateway.networking.x-k8s.io/v1alpha1
kind: XBackend
metadata:
name: ai-provider-api
namespace: ai-apps
spec:
type: ExternalHostname
externalHostname:
hostname: api.ai-provider.com
---
# XBackend'e referans veren HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
spec:
rules:
- backendRefs:
- name: ai-provider-api
kind: XBackend
group: gateway.networking.x-k8s.ioTopluluk ayrıca Session Persistence yapılandırmasını XBackendTrafficPolicy‘den XBackend‘e taşımaya; retry, TLS origination ve benzeri, Route bazlı değil uygulama bazlı yapılandırılması daha anlamlı olan ayarları da bu kaynağa dahil etmeye çalışıyor.
Deneysel kaynaklar standart API grubundan ayrıldı
Daha önce deneysel kaynaklar, standart kaynaklarla aynı API grubunu, yani gateway.networking.k8s.io, paylaşıyor ve yalnızca v1alpha2 gibi sürüm ipuçlarıyla ayrışıyordu. TCPRoute ve UDPRoute bu şema altında Standard’a terfi eden son kaynaklar oldu.
Bundan sonra yeni deneysel kaynaklar ayrı bir grupta, gateway.networking.x-k8s.io altında tanımlanacak ve API tür adları X önekini alacak; XBackend ve XMesh gibi. Bir kaynak Standard’a terfi ettiğinde gateway.networking.k8s.io grubuna yeniden adlandırılıp taşınıyor, X öneki de düşüyor; XMesh’in ileride Mesh olması beklendiği gibi.
Bu ayrım, deneysel/standart sınırını yalnızca sürüm dizesine bakarak değil doğrudan API grubu düzeyinde açık hale getiriyor; hem operatörler hem de araç geliştiricileri için karışıklık ihtimalini azaltıyor.
Uyumlu uygulamalar ve katılım
Duyuru yayımlandığı gün itibarıyla v1.6 ile uyumlu olduğu belirtilen implementasyonlar şunlar:
- Agentgateway
- Airlock Microgateway
- GKE Gateway
- kgateway
- NGINX Gateway Fabric
- Traefik Proxy
Gateway API, Kubernetes SIG Network altında topluluk odaklı bir proje olarak sürdürülüyor. Katkı, geri bildirim ve tartışma için #sig-network-gateway-api Slack kanalı, haftalık SIG Network toplantıları ve kubernetes-sigs/gateway-api GitHub deposu üzerinden katılım sağlanabilir.
Kaynaklar ve İleri Okuma
- Gateway API v1.6: TCPRoute and UDPRoute Graduate to Standard (orijinal duyuru)
- GEP-2644 — TCPRoute
- GEP-2645 — UDPRoute
- TCPRoute Kullanıcı Kılavuzu
- UDPRoute Kullanıcı Kılavuzu
- GEP-4894 — Backend Resource
- EndpointSelector KEP
- Gateway API Dokümantasyonu
- Gateway API v1.5: Altı Özellik Stable Oldu, Ne Değişiyor?
- Ingress2Gateway 1.0: Ingress’ten Gateway API’ye Geçiş
- Kubernetes AI Gateway WG: AI Trafiği Artık Standart
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.
Yorum gönder