Özet: Kubernetes’te trafiği yönetmek için yıllardır varsayılan seçenek olan Ingress, karmaşık senaryolarda yetersiz kalabiliyor. Gateway API, modern trafik yönetimi için daha esnek bir model sunuyor: roller ayrımı, zengin yönlendirme kuralları, taşınabilirlik ve genişletilebilirlik. Bu yazıda, Ingress’ten Gateway API’ye geçişi adım adım anlatıyor, örnek tanımlar ve en iyi uygulamalarla destekliyoruz.
Gateway API Nedir ve Neden Geçmeliyim?
Gateway API, Kubernetes’in ağ katmanında kaynak türlerini genişleterek standartlaştırılmış, sağlayıcıdan bağımsız bir trafik yönetim modeli sunar. Başlıca avantajları:
- Rollerin ayrımı: GatewayClass, Gateway ve HTTPRoute/GRPCRoute/TCPRoute nesneleriyle altyapı ve uygulama ekipleri sorumlulukları net şekilde paylaşır.
- Zengin ifade gücü: Header tabanlı yönlendirme, ağırlıklı trafik bölümü, mTLS, yeniden deneme/politikalar için geniş kapsam.
- Taşınabilirlik ve uyumluluk: Birçok sağlayıcı (NGINX, Kong, Istio, Cilium vb.) aynı API’yi destekler.
- Geleceğe uyum: Topluluk tarafından aktif geliştirilen ve conformance testleriyle doğrulanan bir standart.
Ön Koşullar ve Kurulum
Geçişe başlamadan önce Kubernetes 1.26+ ve seçtiğiniz bir Gateway sağlayıcısı (ör. NGINX, Kong, Istio) kurulu olmalı. CRD’leri etkinleştirmek için aşağıdaki komutu uygulayabilirsiniz (sürüm numarasını güncel olanla değiştirin):
kubectl apply -k "github.com/kubernetes-sigs/gateway-api/config/crd?ref=v1.1.0"
Sağlayıcınıza bağlı olarak bir GatewayClass gelir veya siz tanımlarsınız. Sağlayıcı dökümantasyonunda “GatewayClass name” önemlidir; az sonra Gateway nesnesinde bu ismi kullanacağız.
Ingress’ten Gateway API’ye Geçiş: Adım Adım
1) Mevcut Ingress haritasını çıkarın: Kümelerde hangi alan adları, yollar (path), TLS sertifikaları, backend servisleri ve ağırlıklandırmalar kullanılıyor? Bunları listeleyin. Bu, HTTPRoute’lara dönüşümde yol gösterici olacaktır.
2) GatewayClass ve Gateway tanımlayın: Altyapı ekibi bir GatewayClass sağlar. Ardından trafiğin dinleneceği Gateway nesnesi oluşturulur. Örnek bir Gateway mantığı şöyle olabilir:
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: edge-gw
spec:
gatewayClassName: nginx
listeners:
- name: web
port: 80
protocol: HTTP
- name: web-tls
port: 443
protocol: HTTPS
tls:
mode: Terminate
certificateRefs:
- kind: Secret
name: site-cert
3) HTTPRoute ile yönlendirme oluşturun: Ingress’teki host ve path kurallarını HTTPRoute’a taşıyın. Örnek bir kurgu:
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: shop-route
spec:
parentRefs:
- name: edge-gw
hostnames:
- shop.ornek.com
rules:
- matches:
- path:
type: PathPrefix
value: /api
backendRefs:
- name: shop-api
port: 8080
4) Trafik geçişini risksiz yönetin: Canlı geçişte aynı hostname altında iki servis arasında ağırlıklandırma kullanabilirsiniz. Örnek: eski servis %90, yeni servis %10.
- Ağırlıklandırma: backendRefs altında weight alanını kullanın (ör. weight: 90 ve weight: 10).
- Header tabanlı yönlendirme: Sadece belirli kullanıcı grubuna test için X-Canary: true başlığıyla yeni sürümü gösterin.
- Trafik yansıtma (mirror/tee) özelliği sağlayıcıya göre değişir; destekleniyorsa üretim verisini gölgeleme için kullanın.
5) TLS ve güvenlik: Sertifikaları Secret üzerinden terminate edin. Gateway seviyesinde mTLS veya HTTPRoute bazlı politika tanımlarıyla hassas uç noktaları koruyun. Bazı sağlayıcılar ReferenceGrant ile namespace’ler arası güvenli referanslamayı şart koşar.
6) Gözlemlenebilirlik ve hata ayıklama: Gateway ve Route’ların status alanlarını inceleyin. Olay kayıtları (kubectl describe), metrikler (Prometheus), loglar ve sağlayıcı panellerini birlikte kullanın. Uyuşmayan host veya listener isimleri en sık karşılaşılan kaynaklardır.
Ingress ve Gateway API Arasındaki Farkların Özeti
- Ingress tek bir kaynakla çok şeyi yapmaya çalışır; gelişmiş senaryolarda anotasyon bağımlılığı artar. Gateway API ise modülerdir: Gateway (giriş noktası), Route (uygulama yönlendirmesi) ve Policy (davranış) ayrıdır.
- Birden fazla ekip aynı Gateway’i paylaşabilir; uygulama ekipleri sadece kendi HTTPRoute’larını yönetir.
- Trafik türleri (HTTP, TCP, gRPC) için ayrı Route kaynaklarıyla net ayrımlar sağlanır.
En İyi Uygulamalar
- Adım adım geçiş: Tüm Ingress’leri tek seferde taşımak yerine domain veya mikroservis bazlı fazlara bölün.
- İsimlendirme stratejisi: Gateway, listener ve host adlarını tutarlı belirleyin. Ortak bir etiketleme şeması kullanın (ör. environment, team, cost-center).
- Politikaları merkezileştirin: Zorunlu güvenlik ve hız sınırlama (rate limit) kurallarını gateway seviyesinde; uygulama bazlı esnemeleri route seviyesinde yönetin.
- Conformance kontrolü: Sağlayıcınızın Gateway API uyumluluk seviyesi ve desteklediği ek özellikleri önceden doğrulayın.
- Geri dönüş planı: Canary ve header tabanlı yönlendirmeyle geri alma senaryolarını pratik edin.
Yaygın Hatalar ve Çözümler
- 404/Hostname uyuşmazlığı: HTTPRoute içindeki hostnames listesi, gelen isteğin SNI/Host başlığıyla birebir eşleşmelidir.
- Listener uyuşmazlığı: Route’un parentRefs alanındaki isim, ilgili Gateway listener’ı ile aynı port/protokole uygun olmalı.
- Namespace erişimi: Route’un referans verdiği Service farklı namespace’teyse ReferenceGrant gerektirebilir.
- TLS Secret formatı: tls.crt ve tls.key anahtarları doğru yerleştirilmelidir; yanlış format sertifika yüklenmesini engeller.
Sonuç
Gateway API, Kubernetes’te trafik yönetimini modernleştiriyor. İnce ayarlı yönlendirme, ekipler arası sınırların netleşmesi ve sağlayıcı bağımsızlığı sayesinde büyük ve regüle ortamlarda dahi güvenle ölçeklenebiliyor. Mevcut Ingress’lerinizi envanterleyip küçük adımlarla HTTPRoute’lara taşıyarak, TLS ve politikaları sistematik şekilde uyguladığınızda kesintisiz bir geçiş mümkün. Uzun vadede sade operasyon, daha öngörülebilir davranış ve standart bir ağ katmanı kazanırsınız.
