Kubernetes dünyasında trafik yönlendirme denince yıllardır akla ilk gelen nesne Ingress oldu. Ancak karmaşık topolojiler, çoklu tenant ihtiyaçları ve servis mesh ile entegrasyonlar arttıkça, Ingress’in sınırları da görünür hâle geldi. Tam bu noktada CNCF destekli Gateway API, daha esnek modelleme, tutarlı CRD’ler ve güçlü uzatılabilirlik ile yeni standart olarak öne çıkıyor. Bu yazıda Gateway API nedir, nasıl kurulur ve Ingress’ten geçiş nasıl yapılır ayrıntılı ama sade bir dille anlatıyorum.
Gateway API nedir? Ingress’ten farkları
Gateway API, Kubernetes üzerinde L4/L7 trafiğini tanımlamak için Ingress’e göre daha zengin bir şema sunar. Temel bileşenleri GatewayClass, Gateway ve Route (ör. HTTPRoute, GRPCRoute) nesneleridir. Bu ayrım sayesinde, platform ekibi altyapıyı (GatewayClass/Gateway) yönetirken, uygulama ekipleri yalnızca route’ları tanımlayabilir. Bu da yetki ayrımı, çoklu kiracı desteği ve politika yönetimi açısından büyük avantaj sağlar.
Ingress tek bir kaynak türüyle pek çok ihtiyacı aynı dosyada toplamaya çalışırken, Gateway API yönlendirme mantığını daha modüler ve tutarlı CRD’lere böler. Örneğin birden fazla host, path tabanlı kurallar, TLS sonlandırma, rate limit veya header manipülasyonu gibi gelişmiş özellikler daha net ifade edilebilir. Üstelik aynı manifest’ler farklı sağlayıcılarla daha taşınabilir çalışır.
Hangi uygulamalar destekliyor?
Gateway API bir spesifikasyon; uygulaması ise farklı projeler tarafından sağlanıyor. En popülerleri: Envoy Gateway, NGINX Gateway Fabric ve Istio (mesh senaryolarında doğrudan destekler). Üretim ortamında biriyle başlayıp, mimari ihtiyaçlar değiştiğinde diğerine geçebilmek büyük esneklik sunar. Bu da kilitlenme riskini azaltır.
Kurulum: Hızlı başlangıç
Öncelikle Kubernetes sürümünüzün güncel olduğundan emin olun (en az 1.26+ önerilir). Ardından seçtiğiniz uygulamanın CRD’lerini ve kontrol düzlemini kurun. Örnek olarak Envoy Gateway ile başlamak oldukça rahattır. Resmî manifest’ler ile CRD kurulumu yapılır; akabinde bir GatewayClass ve bir Gateway tanımlanır. Basit bir sınıf tanımı şu şekilde olabilir: apiVersion: gateway.networking.k8s.io/v1 kind: GatewayClass metadata: name: eg-class spec: controllerName: gateway.envoyproxy.io/gatewayclass-controller Sonrasında bu sınıfa bağlı bir Gateway oluşturup trafiğe bir giriş noktası tanımlarsınız: apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: eg-gw spec: gatewayClassName: eg-class listeners: - name: http port: 80 protocol: HTTP
Artık uygulama ekipleri kendi namespace’lerinde HTTPRoute tanımlayabilir. Örnek bir route: apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: web-route spec: parentRefs: - name: eg-gw rules: - matches: - path: type: PathPrefix value: / backendRefs: - name: web-svc port: 8080 Bu tanım, / ile başlayan tüm istekleri web-svc:8080 servisine iletir.
Ingress’ten Gateway API’ye geçiş
Mevcutta Ingress kullanan ekipler için geçiş adımları özetle şu şekilde ilerler: Önce mevcut Ingress kurallarınızı listeleyin ve host/path/TLS mantığını çıkarın. Ardından bir GatewayClass ve Gateway oluşturup, her Ingress kuralını karşılayacak HTTPRoute nesnelerine dönüştürün. Örneğin Ingress’te host: app.example.com ve /api path’i vardıysa, HTTPRoute içinde matches.path ile benzer kuralı tanımlar ve parentRefs ile hedef Gateway’e bağlarsınız.
TLS için Ingress anotasyonları yerine Gateway/Route içinde doğrudan TLS blokları kullanabilirsiniz. Örneğin: listeners: - name: https port: 443 protocol: HTTPS tls: mode: Terminate certificateRefs: - name: app-cert namespace: certs Bu, sonlandırmayı Gateway üzerinde yapar. Eğer uçtan uca TLS istiyorsanız, backend’te de TLS terminasyonu uygulayıp uygun SNI/ALPN ayarlarını yapan bir yapılandırma seçmelisiniz.
Gelişmiş senaryolar: Canary ve mavi-yeşil
Gateway API’de trafik bölme senaryoları sadeleşir. Bir HTTPRoute altında birden çok backendRef tanımlayıp weight ile isteklerin yüzdesini kontrol edebilirsiniz. Örneğin yeni sürüme yüzde 10 trafik göndererek canary testleri yapmak mümkündür. Ayrıca header tabanlı yönlendirme ile yalnızca belirli kullanıcı gruplarını yeni sürüme taşıyarak riskinizi daha da düşürebilirsiniz.
Politikalar, güvenlik ve çoklu tenant
Policy ekosistemi Gateway API’nin güçlü taraflarından. Kuralları namespace sınırlarına göre kısıtlamak, yalnızca belirli ekiplerin belirli listener’lara bağlanmasını sağlamak veya mTLS zorunluluğu getirmek mümkün. Çoğu uygulama, oran sınırlama (rate limit), WAF veya authZ entegrasyonları için ek CRD’ler sunar. Böylece güvenlik ekibi politikaları merkezi tanımlar, uygulama ekipleri ise yalnızca yönlendirme kurallarını yazar.
Sorun giderme: Neleri kontrol etmeli?
Önce CRD ve controller pod’larının sağlığını kontrol edin. Gateway ve HTTPRoute nesnelerinin status alanlarını mutlaka inceleyin; hangi parent’a bağlandığı ve programlama durumunu açıkça gösterir. DNS ve LoadBalancer IP/hostname atamalarını doğrulayın. Trafik gelmiyorsa listener portu, güvenlik grupları ve network policy ayarlarına bakın. Ingress’ten geçişte unutulan en yaygın nokta, TLS terminasyonunun yeri ve sertifika referanslarının namespace’ler arası erişimidir; certificateRefs ve RBAC izinlerini iki kez kontrol edin.
Ne zaman Gateway API’ye geçmeliyim?
Eğer birden çok takım aynı kümede çalışıyor, birden fazla ingress controller’ı yönetmekten yoruluyor veya servis mesh ile uyumlu bir giriş katmanı istiyorsanız, Gateway API güçlü bir aday. Yeni projelerde doğrudan Gateway API ile başlamak, taşınabilirlik ve geleceğe dönük uyumluluk açısından avantaj sağlar. Mevcut Ingress’leriniz basit ve kararlıysa acele etmeye gerek yok; kademeli bir geçiş planı hazırlamak daha sağlıklı olur.
Son söz: Gateway API yalnızca yeni bir CRD seti değil, Kubernetes’te trafik yönetimine bakış açımızı güncelleyen bir standart. Doğru uygulama ve iyi tanımlanmış sorumluluklar ile hem platform ekiplerinin yönetim yükünü azaltıyor hem de uygulama ekiplerine daha net, öngörülebilir bir deneyim sunuyor.
Hiç yorum yok:
Yorum Gönder