Kubernetes Gateway API

 (romaglushko.com)
4 puan yazan GN⁺ 4 시간 전 | 2 yorum | WhatsApp'ta paylaş
  • Kasım 2025’te Kubernetes, tüm kümelerin %40’ından fazlasında kullanılan NGINX Ingress Controller için Mart 2026’da deprecation uygulanacağını duyurdu; bu karar, Gateway API’yi Ingress API’nin halefi olarak konumlandıran bir dönüm noktası oldu
  • Gateway API, gelen trafiği yönetmek için gereken geniş işlev yelpazesini kapsar; Ingress API’ye göre ifade gücü daha yüksektir ve ekipler arasındaki sorumluluk ayrımını daha net hale getirir
  • Ingress API’nin sınırlamaları arasında dar API kapsamı, katı genişletilebilirlik, politika zorlamasının olmaması, belirsiz sahiplik sınırları ve güvenli cross-namespace desteğinin bulunmaması yer alır
  • Gateway API; GatewayClass, Gateway, Listener ve Route gibi ayrıştırılmış bir kaynak modeli ile ReferenceGrant ve Policy attachment gibi güvenlik ve genişletme mekanizmaları sunar
  • NGINX Ingress Controller’da tekrarlanan CVE’ler yapısal kusurlardan kaynaklanır; uzun vadede tek köklü çözüm Gateway API’ye geçiştir

Ingress’in evrim süreci

  • 2014’te erken dönem Kubernetes’te uygulamaları dışa açmanın temel yolu Service kaynağıydı
    • ClusterIP yalnızca küme içi DNS adı sağlar, dışarıdan erişim mümkün değildir
    • NodePort, tüm düğümlerde belirli bir port açarak dış trafiği kabul eder; düğüm IP’si açığa çıkarsa dış erişim mümkün olur
    • LoadBalancer, herkese açık IP’ye sahip harici bir yük dengeleyici provision ederek trafiği iletir
    • ExternalName, bir CNAME kaydıyla harici bir hizmet için küme içinde takma ad sağlar
  • Dördü arasında doğrudan dışa açılabilenler yalnızca NodePort ve LoadBalancer’dır
    • NodePort temel bir primitive’tir ancak fazla düşük seviyelidir; düğümler arası harici yük dengeleme ile path tabanlı yönlendirmeyi doğrudan sizin uygulamanız gerekir
  • LoadBalancer, NodePort üzerine L4 load balancer (TCP/UDP) ekleyerek otomatik provisioning sağlar; bunu Cloud Controller Manager üstlenir
    • Ancak çok sayıda genel IP ve yük dengeleyici yönetmek gerektiğinden maliyet artar ve trafiği merkezi olarak yönetecek bir nokta bulunmaz
  • Her Service için ayrı bir yük dengeleyici yerine, tüm trafiği alan tek bir LoadBalancer Service’in bunu NGINX benzeri bir reverse proxy Deployment’ına iletip yol ve host adına göre yönlendirdiği yapı, Ingress API ile Ingress Controller’ın çıkış noktası oldu

Ingress Controller

  • 2015’te Kubernetes ekibi, harici HTTP(S) trafiğini iç Service’lere yönlendirme kurallarını tanımlamanın yolu olarak Ingress API’yi tanıttı

  • Ingress API, IngressClass ve Ingress olmak üzere iki kaynaktan oluşur; yalnızca ortak arayüzü tanımlar ve fiili davranış için bir Ingress Controller kurulması gerekir

  • IngressClass

    • Hangi denetleyicinin belirli bir Ingress kaynak kümesini işleyeceğini belirleyen cluster-wide bir kaynaktır
    • Aynı kümede birden fazla Ingress Controller’ın eşzamanlı çalıştırılmasını mümkün kılar; her denetleyici yalnızca kendi IngressClass’ı tarafından seçilen kaynakları izler
    • Denetleyicinin IngressClass’ı okuyup kullanabilmesi için ClusterRole yetkisi gerekir

  • Ingress kaynağı

    • Ingress, Ingress API’nin ana kaynağıdır ve birden fazla unsuru bir araya getirir
      • path tabanlı (exact/prefix) ve host tabanlı eşleme kurallarıyla iç Service yönlendirmesini tanımlar
      • gelen trafiğin TLS ayarlarını tanımlar
    • Kaynak oluşturulduğunda Ingress Controller bunu algılar, kendi yapılandırmasını günceller ve yönlendirme kurallarını uygular

  • Ingress API’nin sorunları

    • Gerçek işletim ortamlarında şu sorunlar ortaya çıktı: son derece sınırlı API kapsamı, katı genişletilebilirlik, politika zorlamasının olmaması, belirsiz sahiplik sınırları ve güvenli cross-namespace desteğinin bulunmaması

  • Son derece sınırlı API kapsamı

    • Ingress API basit olmaktan çok aşırı yalın (simplistic) bir yapıdadır; ingress trafiği yapılandırması için gereken asgari unsurlarla sınırlıdır
    • NGINX’te sık istenen şu özellikleri doğrudan desteklemez
      • request timeout, CORS, max body size sınırı, sticky cookie oturumu, canary trafik bölme, rate limiting, header·query·cookie tabanlı yönlendirme, header değiştirme
    • Bu nedenle ek yapılandırma aktarmanın standart yolu custom annotation oldu; Traefik gibi bazı denetleyiciler kendi CRD’lerini kullanır
    • Birden fazla Ingress Controller aynı anda kullanıldığında birleşik bir yapılandırma yöntemi olmadığından, annotation’lar denetleyiciye göre değişir ve taşınabilirlik düşer
    • Ingress yalnızca HTTP(S) yönlendirmesini kapsar; gRPC (L7), TCP ve UDP (L4) ise uygulamaya göre custom annotation ile ele alınır

  • Katı genişletilebilirlik

    • custom annotation yalnızca string key-value çiftlerinden oluştuğu için, karmaşık yapılandırmaların string olarak serileştirilmesi gerekir; bu da ifade gücünü sınırlar

  • Politika zorlamasının olmaması

    • Uygulama ekipleri Ingress kaynağına istedikleri annotation’ı ekleyebilir; örneğin platform ekibinin tüm rotalarda beklediği rate limiting’i devre dışı bırakabilir
    • Ingress API’nin kendisinde küresel davranışı zorlayacak bir mekanizma olmadığından Kyverno veya OPA Gatekeeper gibi harici politika motorlarına bağımlıdır

  • Belirsiz sahiplik sınırları

    • Ingress kaynağı birden fazla yapılandırmayı iç içe geçirir
      • yönlendirme kuralları genellikle uygulama ekibinin sorumluluğundadır
      • hostname ve port ayarları, DNS, load balancer ve ağı yöneten platform ekibinin sorumluluğundadır
      • TLS ayarları, sertifika provisioning’inden sorumlu platform ekibine aittir
      • custom annotation ise iki ekipten herhangi birine ait olabilir
    • umbrella Helm chart ile dağıtılan karmaşık sistemlerde Ingress genellikle uygulama subchart’ında yer alır, ancak platform ekibinin de bazı bölümleri güncellemesi ve zorlaması gerekir
    • tek sorumluluk ilkesi açısından Ingress’in birden fazla değişim nedeni vardır; bu yüzden daha odaklı kaynaklara ayrılması tercih edilir
    Reklam

  • Güvenli cross-namespace desteğinin olmaması

    • Ingress kaynağı, kendi namespace’i dışındaki Service veya TLS secret’larına referans veremez; rules[].backend.service içinde namespace belirtmeye yarayan bir alan bile yoktur
    • Geçici çözüm olarak aynı namespace içinde, hedef Service’in küme içi DNS adını işaret eden bir ExternalName Service oluşturulabilir
    • Ancak bu yaklaşım doğrudan confused deputy attack kapsamına giren bir sorunu da beraberinde getirir

Gateway API

  • Gateway API, Ingress API’nin yeni nesil sürümüdür ve şu yollarla bu sınırlamaları giderir
    • gelen trafiği yönetmek için gereken çok daha geniş özellikleri kapsar ve ifade gücünü artırır
    • yaygın kaynak sahipliği kalıplarını yansıtarak ekipler arasında sorumluluk ayrımını netleştirir
    • policies adı verilen tanımlı genişletme mekanizmasını ve esnek cross-namespace nesne referanslarını içerir

GatewayClass

  • IngressClass’a benzer biçimde, belirli bir Gateway controller dağıtımının sahip olduğu Gateway kümesini tanımlar; anlam ve yapı olarak fiilen IngressClass ile aynıdır
  • Ek uygulamaya özgü Gateway yapılandırmasını içeren bir custom resource’a referans verebilir
    • Gateway proxy’nin dışa açılma biçimi, bootstrap ve çalışma zamanı varsayılan ayarları, dağıtım rollout ve ölçekleme şekli ile denetleyiciye özgü diğer seçenekler buna dahildir

Gateway

  • Gateway kaynağı, dinamik olarak provision edilen bir edge gateway’i temsil eder; gelen trafiği alıp uygun backend service’lere yönlendiren altyapı soyutlamasıdır

    • Ingress tasarımında bu rolü Ingress Controller üstlendiğinden, bunu statik olarak provision edilmiş bir Gateway örneği olarak görmek mümkündür

  • Her Gateway, hangi denetleyicinin onu provision edip yöneteceğini belirtmek için bir GatewayClass’a referans verir; en önemli bileşeni ise listener listesidir

  • Listener'lar

    • Gateway'nin gelen trafiği nasıl kabul ettiğini tanımlar; her listener, port·protocol·hostname birleşimiyle tanımlanan ayrı bir giriş noktasıdır
    • TLS termination yapılandırılabilir; Ingress dünyasında bu bilgi Ingress kaynağının içinde bulunuyordu
    • Bir Route'un Gateway'ye attach edilebileceği en ayrıntılı birimdir

  • ListenerSet

    • listener, giriş noktası yapılandırmasını merkezileştirmek için iyidir ancak yüzlercesine ihtiyaç duyulduğunda uygun değildir
    • Başlıca kullanım örneği, tek bir wildcard TLS sertifikası yerine hizmet başına hostname·TLS yapılandırmasına sahip HTTPS listener'lardır; mikroservis sayısı kadar listener oluşabilir
    • Tek bir Gateway olarak modellendiğinde iki sorun ortaya çıkar
      • Gateway en fazla 64 listener destekler
      • Birden çok ekip listener·TLS yönetirse Gateway koordinasyon için bir darboğaz haline gelir
    • Bunu dağıtık ve çok kiracılı hale getirmek için ListenerSet kaynağı kullanılır

  • İzin verilen Listener ve Route'lar

    • Gateway ve Route kavramları ayrıldıktan sonra, hangi kiracının hangi listener'a Route attach edeceğini kontrol etme şeklinde yeni bir sorun ortaya çıkar
    • listener paylaşılan bir altyapıdır ve kullanım amacı farklılık gösterebilir; örneğin veritabanına passthrough kanalı olan tls-passthrough-db listener'ına HTTPRoute bağlamak uygun değildir, ayrıca db dışındaki namespace'lerden Route bağlanması da uygun değildir
    • Route'lar özerk bir yönetim modeliyle eklendiğinden, yanlış yapılandırmayı önlemek için allowedRoutes mekanizması kullanılır
    • allowedRoutes, Gateway·ListenerSet ile belirli namespace ve route türlerindeki Route'lar arasında bir güven ilişkisi kurar

Route'lar

  • listener trafiği alır ancak sonrasında nasıl işleneceğini bilmez; bunu Route kaynakları üstlenir ve bu, Gateway API esnekliğinin merkezindedir

  • Farklı protokolleri ele alan beş Route kaynağı vardır

    • HTTPRoute: geliştirilmiş ve genişletilmiş HTTP trafik yönlendirmesi
    • GRPCRoute: gRPC farkındalığına sahip yönlendirme
    • TLSRoute: TLS SNI tabanlı yönlendirme
    • TCPRoute·UDPRoute: listener portundaki TCP/UDP trafiğini doğrudan backend'e iletir
    Reklam

  • Tüm Route kaynakları (topluca xRoutes) benzer bir envelope yapısına sahiptir

    • parentRefs, Route'u kabul eden üst kaynağa (çoğunlukla Gateway, ListenerSet, service mesh'teki Service vb.) yönelik typed object reference'tır; isteğe bağlı sectionName·port ile belirli bir listener belirtilebilir
    • rules, protokole özgü yönlendirme kuralları·filtreler·ayarları içerir; her rule, matches, isteğe bağlı filters ve isteğe bağlı backendRefs bileşenlerinden oluşur; filtre isteği tamamen işlerse backendRefs atlanabilir
    • Protokol izin veriyorsa hostnames alanıyla Route düzeyinde host tabanlı yönlendirme yapılabilir

  • HTTPRoute

    • L7 seviyesinde HTTP(S) trafiği için yönlendirme kurallarını tanımlar

    • Traffic Matching

      • Ingress'e benzer path·host tabanlı yönlendirme ile header·query·method tabanlı eşleştirme kurallarını destekler
      • Örneğin yalnızca iç istemciler için canary release'i, header tabanlı eşleştirmeyle test deployment'ına yönlendirmek mümkündür
      • Veri düzlemi en spesifik kuralı uyguladığından, kuralların tanımlanma sırası önemli değildir

    • URL Rewrites

      • Filtre kullanılarak backend'e ulaşmadan önce istek URL'sinin bir kısmı rewrite edilebilir

    • Header Modifications

      • request·response header'larını ekleyen·kaldıran·değiştiren HeaderModifier filtresi sunulur
      • Cross-Origin Resource Sharing yapılandırması için özel bir CORS filtresi sunulur; kavramsal olarak response header değiştirmenin özel bir durumu olsa da ayrı bir filtre türü olarak sunulur

    • Redirects

      • Backend'e iletmek yerine istemciye redirect yanıtı döndürülebilir; 3xx path tabanlı redirect ve HTTP→HTTPS redirect desteklenir

    • Traffic Control

      • weight ile backend servisleri arasında trafik bölünebilir; blue-green dağıtımı ve A/B testleri gibi senaryolarda kullanışlıdır
      • traffic mirroring, production trafiğinin bir kopyasını ek bir backend'e gönderir ve RequestMirror filtresiyle yapılandırılır; asıl istek varsayılan backend'e gitmeye devam eder
      • mirroring, refactoring ve migration sırasında eski ve yeni sürümlerin sonuçlarını karşılaştıran tap-and-compare testing için temel bir bileşendir

    • Sticky Sessions

      • Session persistence desteklenir; cookie ve header, oturum işaretçisi olarak ayarlanarak aynı istemciden gelen isteklerin tutarlı biçimde aynı backend instance'ına yönlendirilmesi sağlanır

    • External Authentication

      • gRPC veya HTTP tabanlı deneysel external authentication filtresi desteklenir; Gateway, backend'e iletmeden önce istek header'larını harici kimlik doğrulama servisine gönderir, istek gövdesi ise yalnızca açıkça etkinleştirildiğinde gönderilir
      • gRPC durumunda harici kimlik doğrulama servisinin Envoy'un ext_authz protobuf API'sini uygulaması gerekir
      • HTTP durumunda kimlik doğrulama başarılıysa 200 döndürülür; diğer tüm durum kodları kimlik doğrulama başarısızlığı olarak değerlendirilir

    • Retries & Timeouts

      • Belirli route'larda retry ayarlanabilir; BackendTrafficPolicy, retry storm'u önlemek için genel bir retry budget sağlar

  • GRPCRoute

    • gRPC, HTTP/2 tabanlı olduğu için HTTPRoute ile de işlenebilir, ancak bunun ayrı bir kaynak olarak modellenmesinin nedenleri vardır
      • URL rewrite gibi gRPC için anlamsız olan seçenekleri ayırarak her kaynağın protokole uygun şekilde bağımsız gelişmesini sağlar
      • gRPC yanıtları HTTP 200 döndürürken uygulama hatalarını grpc-status ve grpc-message header'larıyla ifade eder; bu, doğru retry ve metrikler için önemlidir
      • Kuralların daha üst düzey gRPC terimleriyle tanımlanması kullanıcı deneyimini iyileştirir
    • HTTPRoute'taki path matcher, method matcher ile değiştirilmiştir; iç tarafta path eşleştirilse de service·method biçiminde sunulur
    • request·response header işleme mümkündür ancak gRPC payload decode edilmediği için belirli protobuf alanlarına göre yönlendirme yapılamaz
    • traffic mirroring, weighted load balancing ve header değiştirme gibi HTTPRoute filtrelerinin bir kısmını destekler

  • TCPRoute ve UDPRoute

    • listener portuna ulaşan trafiği basitçe backend servisine iletir; şu anda matcher ve filtre desteklenmez
    • Her iki tür de birden fazla backend arasında weighted load balancing destekler

  • TLSRoute

    • TLS handshake sırasında sağlanan SNI temel alınarak TLS ile şifrelenmiş trafik backend'e yönlendirilir
    • Ağırlıklı olarak TLS passthrough için kullanılır; Gateway, SNI'yi inceleyip backend'i seçtikten sonra TLS sonlandırması yapmadan şifreli bağlantıyı iletir, TLS sonlandırmasını backend üstlenir
    • Envoy Gateway veya kgateway gibi bazı implementasyonlar edge'de TLS termination da destekler, ancak bu bir genişletme özelliğidir
    • Route'ta hostname belirtilmesi gerekir; bu, SNI değeriyle eşleşmeli ve Gateway listener'ının hostname'iyle kesişmelidir; matcher ve filtre desteklenmez ancak weighted load balancing desteklenir

  • Route Filter Extensions

    • HTTPRoute ve GRPCRoute, extensionRef filtresiyle custom filtreler ve request/response işleme için bir genişletme mekanizması içerir; bu, başka bir kaynağı işaret eden typed object reference'tır
    • Örneğin Envoy Gateway, backend servisi olmadan doğrudan yanıt döndüren bir HTTPRouteFilter CRD'si sunar

  • Backend Hedefleri

    • Varsayılan olarak standart Service (en yaygın olanı) ve çoklu küme için ServiceImport arka uç hedefi olarak desteklenir
    • typed object reference ile belirtildiği için uygulamaya özel custom resource’larla genişletilebilir
    • Örnek: Envoy Gateway, FQDN, IP, UNIX soketi gibi harici upstream’leri işaret eden özel bir Backend kaynağını destekler
    Reklam

  • ReferenceGrant

    • Gateway API, namespace’ler arası referansları standart tasarımın birinci sınıf kavramı olarak ele alır, ancak güvenlik riski vardır
    • confused deputy attack örneği: Saldırgan bir namespace’i ele geçirirse, Ingress, Service ve EndpointSlice oluşturma yetkileriyle korunan servislere erişimi sızdırabilir
      • Yeni bir Ingress, ele geçirilmiş namespace’teki yeni bir Service’i işaret eder
      • Bu Service selectorless olduğu için hiçbir deployment ile eşleşmez ve elle EndpointSlice sağlanabilir
      • Saldırgan, başka bir namespace’teki korumalı arka uç pod IP’lerini içerecek şekilde EndpointSlice sahteleyip port hizalamasıyla korunan API’ye ikinci bir giriş yolu oluşturur
      • Aynı sonuca ExternalName Service ile de ulaşılabilir
    • Bunu azaltmak için ReferenceGrant kaynağı eklendi; bir namespace’in, kendi kaynaklarına hangi namespace’lerin referans verebileceğini tanımladığı çift yönlü bir güven mekanizmasıdır
    • Gateway Controller, arka uç hedeflerine ve TLS secret’larına namespace’ler arası referanslarda ReferenceGrant’i dikkate alır; bu da confused deputy attack’ı zorlaştırır
    • Ancak ReferenceGrant yalnızca referansın meşruluğunu garanti eder; trafik iletildikten sonraki davranışa müdahil olmaz. Korumalı API portlarına erişimi engellemek için NetworkPolicies ile tamamlanabilir

Policies

  • Policy attachment, özgün kaynağı değiştirmeden bir veya daha fazla Gateway API bileşenine davranış ve etkiyi hiyerarşik olarak uygulayan güçlü bir genişletme desenidir
  • Kimlik doğrulama bunun tipik örneğidir
    • Gateway’nin (veya ListenerSet’in) tamamına kimlik doğrulama uygularsanız, şu an ve gelecekte bağlanacak tüm Route’lar hiyerarşik olarak etkilenir; aynı zamanda herkese açık route’lar gibi Route düzeyinde istisnalar tanımlanabilir
    • Kimlik doğrulama, Gateway ve Route’tan bağımsız bir ekip tarafından kontrol edilebilir; bu yüzden ilgili kaynakları doğrudan değiştirmeden çalışacak şekilde tasarlanmıştır
    • OAuth 2 ve OIDC gibi standartlar olsa da kimlik doğrulama yapılandırması uygulamaya yüksek derecede bağımlıdır; tüm uygulamalarda geçerli olacak bir soyutlama oluşturmak zordur
  • Örnek: Envoy Gateway’nin SecurityPolicy kaynağıyla JWT token doğrulaması yapılandırılır; Policy, Ingress dönemindeki annotation tabanlı yapılandırmanın yerini alan modern ve ifade gücü yüksek bir yöntemdir
  • Yerleşik Policy sayısı yalnızca ikidir
    • BackendTLSPolicy: Gateway’ye upstream arka uca TLS ile bağlanmasını söyler
    • BackendTrafficPolicy: Belirli bir arka uç için retry budget tanımlar; genel retry kotası aşılırsa 503 döner ve circuit breaker gibi çalışarak retry storm’u önler

Ownership

  • Küme içindeki Gateway API kaynakları genellikle iki ekip tarafından sahiplenilir
    • Platform team, GatewayClass, Gateway, ListenerSet ile LoadBalancer ve TLS yapılandırmasını tanımlar; Gateway’in bir kısmına veya tamamına uygulanan global Policy’leri yönetebilir
    • Application/Service team ise çoğunlukla kendi Route kaynaklarına odaklanır ve gerektiğinde Route düzeyinde Policy uygular
  • Esnekliği yüksektir; örneğin Route’ların platform ekibi tarafından tek bir namespace’te toplanıp sahiplenildiği gibi farklı sahiplik modelleri kurulabilir

Tipik Mimari

  • Gateway API, uygulama mimarisi hakkında büyük varsayımlarda bulunmaz; ancak yaygın yaklaşım control plane ile data plane’in ayrılmasıdır
  • Gateway Controller, control plane rolünü üstlenen bir Kubernetes operator’üdür; Gateway API kaynakları ve CRD’leri izleyerek istenen data plane yapılandırmasını derler, kaynakları okumak ve değiştirmek için genişletilmiş yetkilere ihtiyaç duyar
  • Gateway data plane, yapılandırmaya göre trafiği işleyen proxy’dir; çoğunlukla Envoy Proxy, NGINX, Traefik vb. kullanılır; uygulamaya bağlı olarak her Gateway için ayrı proxy sağlanabilir ya da paylaşılabilir
  • control/data plane ayrımı, NGINX Ingress Controller’da görülen temel güvenlik kusurlarından kaçınmak için avantajlı bir tasarım tercihidir

Ingress geçişi

  • NGINX Ingress Controller deprecation durumuna karşı dört seçenek vardır; en az müdahaleci olandan başlayarak değerlendirilir

  • Hiçbir Şey Yapmamak

    • En iyi seçenek değildir, ancak bazı durumlarda mümkündür; homelab ortamlarında motivasyon düşük olabilir

    • Kurumsal ortamda ise bakımı yapılan ve yamalanan yazılım çalıştırmayı bekleyen regülasyon, güvenlik ve uyumluluk çerçeveleri nedeniyle kabul edilmesi zordur

      • ISO 27001: zafiyet yönetimi, yamalama ve EOL takibi beklenir
      • SOC 2 Type II: zafiyet taraması, yama yönetimi ve düzeltme SLA’leri beklenir
      • HIPAA Security Rule: eski ve yamalanmamış yazılımın risk analizine dahil edilmesi gerekir
      • PCI DSS v4.0.1: desteklenmeyen bileşenlerin tespiti ve düzeltme planı ister, kritik zafiyetler için müdahale süresi tanımlar
      • FedRAMP: desteklenmeyen yazılımın bakımı yapılan alternatiflerle değiştirilmesini bekler, önem derecesine göre düzeltme süreleri vardır

    • Çoğu çerçevede EOL yazılım, yeni zafiyetler açıklandığında fiilî bir sorun haline gelir

    • CVE analizi

      • Son 5 yıldaki NGINX Ingress Controller CVE görünümü
        • Toplam 20 zafiyet
        • 2021’de secret sızıntısıyla ilgili High seviyesinde 4 adet
        • 2022’de controller credential sızıntısıyla ilgili High seviyesinde 1 adet
        • 2023~2024 döneminde High seviyesinde 3 adet
        • 2025’te 6 adet; buna 1 Critical (IngressNightmare) ve NGINX yapılandırma enjeksiyonuyla ilgili 4 High dahil
        • 2026’da 6 adet; buna NGINX yapılandırma enjeksiyonuyla ilgili 3 High dahil
      • 2021~2022 CVE’leri çoğunlukla annotation içindeki arındırılmamış kullanıcı kaynaklı NGINX yapılandırmasından kaynaklandı; yapılandırma enjeksiyonu, bilgi ifşası ve secret sızıntısına yol açtı, bunun üzerine Kubernetes doğrulama ekledi
      • 2023~2024 CVE’leri ise büyük ölçüde bu annotation doğrulamasını aşmaya odaklandı
      • IngressNightmare (CVE-2025-1974) durumu daha da kötüleştirdi: Önceden Ingress kaynağı oluşturma veya değiştirme yetkisi gerekirken, artık admission controller’a ağ erişimi olan biri, yapılandırma enjeksiyonuna benzer bir hata üzerinden ingress-nginx controller bağlamında uzaktan kod çalıştırabilir; ardından controller’ın erişebildiği Secret’lar sızdırılabilir
      • 2026 serisi de annotation, path ve comment üzerinden yapılandırma enjeksiyonu deseninin sürdüğünü gösterdi
      • Bu zafiyetler, tasarımdaki aynı zayıflığı tekrar tekrar hedef aldı
        • Controller çok esnektir ve geniş NGINX özelliklerini açığa çıkarır; bu yüzden kusursuz doğrulama zordur ve yapılandırma enjeksiyonu tekrar tekrar ortaya çıkar
        • Controller, control plane ile data plane’i aynı pod içinde çalıştırır ve dosya sistemini paylaşır; bu da bir olay yaşandığında etki alanını büyütür
        • Controller çoğu zaman küme genelindeki Secret’lara erişir; bu nedenle yapılandırma enjeksiyonunun başarıya ulaşması küme çapında secret sızıntısına dönüşebilir
      • Yapısal sorunlar nedeniyle gelecekte de ek CVE’ler beklenir; bir geçiş planı olmadan özgün controller’da kalmak riskli bir tercihtir
      Reklam

  • NGINX Controller fork’u kullanmak

    • En basit yol, bakımı süren bir fork’a geçmektir
      • Chainguard fork’u, derlenmiş imajlar sunmuyor gibi görünüyor; bu da sunduğu ürünün bir parçası
    • Yeni CVE’lere maruz kalma riskini azaltır ve büyük değişiklik yapmadan sistemi sürdürmeyi sağlar, ancak kısa vadeli bir çözümdür
    • Chainguard, controller’ı uzun vadeli bir proje olarak geliştirmeyi hedeflemiyor; bunun yerine kullanıcılara geçiş için zaman kazandırmak amacıyla best-effort CVE düzeltmeleri sağlıyor

  • Başka bir Ingress Controller kullanmak

    • Ingress kaynağının kendisi deprecated olmadığı için, bakımını sürdüren başka bir Ingress Controller’a geçmek de geçerli bir seçenek; başlıca örnekler HAProxy·Istio·Traefik
    • Sistem genelinde annotation migration’ı gerekir; zorluk seviyesi NGINX’e özgü özelliklere bağımlılık derecesine göre değişir
    • Gelecekte daha fazla proje Gateway API’ye geçtikçe Ingress’in ağırlığı azalacak olsa da, bir süre daha Ingress kullanmakta yeterince sakınca yok

  • Gateway API’ye migration

    • Tek uzun vadeli seçenek, Ingress API’den Gateway API’ye geçiştir
      • Gateway API CRD’lerini ve implementasyonu kurma
      • GatewayClass·Gateway·gerekirse Policy kaynaklarını yapılandırma
      • Mevcut Ingress kaynaklarını Route’lara taşıma
    • Kubernetes ekibinin geliştirdiği ingress2gateway CLI aracı, best-effort otomatik dönüşüm sunar; custom annotation’ların sonradan elle yeniden doğrulanması gerekir
    • timeout, dosya yükleme limiti, body size limiti gibi ayarların doğru şekilde taşınması gerekir; eksik ya da hatalı eşleme, uygulamanın varsayımlarını sessizce bozabilir
    • Ingress Controller’ın LoadBalancer’ından yeni Gateway proxy’nin LoadBalancer’ına trafik geçişi dikkatle planlanmalıdır; bunun big-bang olması gerekmez
      • Ingress Controller geçici olarak herkese açık giriş noktası olarak tutulup, yalnızca trafiğin bir kısmı Gateway API data plane’ine yönlendirilerek gerçek trafik üzerinde test yapıldıktan sonra kademeli geçiş yapılabilir

Hangi Gateway seçilmeli

  • Migration kararı verildikten sonraki ilk büyük soru, hangi Gateway API implementasyonunun kullanılacağıdır

  • Bu yazıdaki generic API Gateway kullanım tanımı: tamamen kontrol edilen bir ortama dağıtılan, public North-South trafiği için ölçeklenebilir bir gateway; yaygın kimlik doğrulama kalıplarını ve esnek rate limiting’i varsayılan olarak sağlar

  • API Gateway dışında LLM Gateway ve Agent Gateway de vardır, ancak bu bölüm klasik API Gateway’e odaklanır

  • Gateway API Conformance

    • Kubernetes ekibi, implementasyonların çekirdek protokol işleme doğruluğunu doğrulayan standart conformance testleri hazırladı; bunlar ağırlıklı olarak işlevsel davranışa odaklanır, güvenilirlik·performans·ölçeklenebilirlik·operasyonel karmaşıklık gibi işlevsel olmayan yönleri kapsamaz
    • conformant implementasyonlar tercih edilmelidir; resmi sitede sonuç yoksa maintainer’dan conformance raporu istenmesi önerilir

  • Public Benchmarks

    • Resmi testlerin dışında güvenilirlik ve performansı ele alan açık benchmark’lar da vardır; Istio katkıcısı ve Solo.io çalışanı John Howard, başlıca implementasyonlar için benchmark’lar hazırlamıştır; Solo.io, kgateway’in ana şirketidir
    • Route attachment·yayılım·ölçek·genel trafik işleme performansı gibi yararlı test senaryoları içerir; kişisel deneyime dayandığı için belirli kullanım senaryolarına yatkın olabilir, ancak değerlendirme için bir bakış açısı olarak kullanılabilir

  • OSS vs Proprietary

    • Günümüzde güçlü, production seviyesinde pek çok OSS Gateway API implementasyonu bulunduğundan, değerlendirme sırasında bunlar ciddi biçimde dikkate alınmalıdır; birçok organizasyon için OSS varsayılan başlangıç noktasıdır
    • OAuth2·OIDC gibi geçmişte ticari ürün satın almayı haklı gösteren özellikler artık commodity hâline gelmiştir; OSS controller’lar da bunları varsayılan olarak sunar
    • OSS’de taahhütte bulunmadan önce kaliteyi doğrudan değerlendirmek mümkündür; ticari ürünlerde ise vendor’a erken aşamada güvenmek gerekir

  • Recommendations

    • data plane’e göre gruplama

      • Envoy Proxy tabanlı: Envoy Gateway, Istio, Cilium, kgateway vb.
      • NGINX tabanlı: NGINX Gateway Fabric, Kong
      • Diğer proxy’ler: HAProxy Ingress, Traefik

    • Envoy Gateway

      • Envoy Proxy ekibinin geliştirdiği, Envoy Proxy tabanlı açık kaynaklı bir Gateway API controller’ıdır; Envoy özelliklerini Gateway API’ye mümkün olduğunca doğrudan eşlediği için, Istio’ya kıyasla ürüne özgü soyutlama daha azdır ve anlaşılması daha kolaydır
      • Ingress API’yi desteklemez; Envoy AI Gateway ile LLM·MCP gateway·Inference Pools özelliklerine genişletilebilir
      • Hafiftir, dağıtımı ve işletimi basittir, API Gateway (North-South) kullanımına odaklanır; desteklenen özellikler şunlardır
        • external authentication·JWT doğrulama·JWT claim tabanlı authorization·OIDC·IP allowlisting·static API key kimlik doğrulaması·credential injection gibi güvenlik kalıpları
        • global ve route seviyesinde yapılandırma, shadow mode, request cost ayarı gibi yeteneklere sahip esnek bir global rate limit policy
        • connection·bandwidth·dosya boyutu sınırları, availability zone farkındalıklı routing, ServiceImport tabanlı varsayılan multi-cluster, Brotli·gzip·zstd response compression, direct response·response override
        Reklam
      • Genişletilebilirliği de yüksektir: istek·yanıt·xDS yapılandırmasını değiştirmek için gRPC servisleri yazılabilir; Lua veya WASM’e derlenebilen dillerle (Go·Rust) plugin geliştirilebilir
      • FQDN·IP dış kaynaklarını ve sidecar için UNIX socket’i işaret eden custom Backend kaynağını içerir
      • Şu anda bazı skip edilen testler nedeniyle partially conformant olarak listelenir, ancak işlevsel olarak neredeyse tüm maddeleri karşılar; KEDA·KNative gibi CNCF projeleriyle entegredir
      • Yalnızca özellik açısından zengin bir API Gateway gerekiyorsa iyi bir seçenektir

    • Istio

      • Envoy Proxy tabanlı bir service mesh ve aynı zamanda CNCF Graduated projesidir; Gateway API testlerinde conformant olarak listelenmiştir
      • Ingress Controller·Gateway API controller’ı·service mesh içeren bir pakettir; agentgateway entegrasyonu ile LLM·MCP·A2A gateway işlevleri sunabilir
      • Admiral vb. ile gelişmiş multi-cluster desteği, geniş deployment profilleri, büyük bir topluluk ve O'Reilly kitapları gibi bol kaynak sunar; mTLS tabanlı pod-to-pod şifreleme sayesinde kamu ve FedRAMP ortamları için faydalıdır
      • Dezavantaj olarak sidecar modunda kaynak tüketimi yüksektir ve çok sayıda kendine özgü kavrama sahip olduğundan öğrenme eğrisi diktir
      • ambient mode ile hafif bir kurulum sunar, ancak gelişmiş L7 kullanım senaryolarında sidecar kadar işlevsel olmayabilir; daha güçlü policy ve L7 kontrolü gerekiyorsa Envoy Gateway’in ingress gateway ve waypoint proxy olarak birlikte kullanılması düşünülebilir
      • service mesh öncelikliyse ve Gateway API ikincilse en iyi seçenektir; yalnızca bir API gateway gerekiyorsa biraz yetersiz gelebilir

    • kgateway

      • Gloo projesi tabanlı, açık kaynaklı CNCF Sandbox bir gateway’dir; data plane olarak Envoy Proxy ve agentgateway (AI gateway özellikleri) destekler, ayrıca dışarıdan yönetilen kendi data plane instance’larını kullanabilir
      • Tam Gateway API conformance ile, neredeyse benzersiz biçimde tüm maddeleri karşılar
      • Envoy data plane üzerinde JWT doğrulama·OAuth2/OIDC·external authentication·IP erişim kontrolü, Envoy global rate limiting, ext_proc tabanlı istek·yanıt işleme sunar; ancak Lua·WASM plugin’lerini veya raw xDS’nin doğrudan düzenlenmesini görünüşe göre sunmaz
      • MiniJinja şablon tabanlı güçlü transformation motoru sayesinde TrafficPolicy kaynağında header·response body·status dönüşümleri deklaratif olarak tanımlanabilir
      • Istio ile edge proxy olarak entegre olabilir ancak kendi başına bir service mesh değildir; bir Route’un trafik işlemeyi başka bir Route’a devrettiği hiyerarşik Route yapısını destekler, ayrıca AWS Lambda’yı doğrudan çağıran custom AwsLambda CRD’sine sahiptir
      • Vendor’ın geniş deployment iddialarına rağmen bağımsız geri bildirim fazla olmadığından, açık topluluk perspektifinden bakıldığında hâlâ büyüme aşamasında bir proje gibi görünmektedir

  • Traefik

    • Go ile yazılmış popüler açık kaynak reverse proxy; hem Ingress API hem de Gateway API’yi destekler, güçlü dokümantasyonu, düzenli kod tabanı, basit yapılandırması ve kolay dağıtımı sayesinde özellikle homelab topluluğunda popülerdir

    • Temel Gateway API özelliklerini ve bazı ek özellikleri destekler ancak ListenerSet ile Gateway API üzerinden traffic mirroring henüz desteklenmez (custom TraefikService backend ile mirroring mümkündür)

    • Genişletme modeli middleware tabanlıdır; ExtensionRef filtresiyle Route’u Middleware CRD’ye bağlar, yerleşik middleware olarak ForwardAuth (harici kimlik doğrulamayı devretme, Envoy ext_authz’e benzer), IP allowlisting ve CORS, bağlantı sınırları, retry ve circuit breaker, sıkıştırma, custom error page gibi özellikler sunar

    • Plugin middleware ile custom YAEGI ve WASM eklentileri bağlanabilir (çoğunlukla istek ve yanıt değiştirme için); JWT doğrulama, OIDC ve OAuth2 Client Credentials yalnızca ücretli eklentilerle sunulur

    • Middleware CRD ile temel dağıtık rate limiting desteği sunar (IP, host ve header bucket’ları) ancak yapılandırma esnek değildir ve policy attachment yerine ExtensionRef ile bağlandığından, genel uygulama sonrası route düzeyinde override gibi katmanlı kullanım zordur

    • Belirgin bir control/data plane ayrımı yoktur; bu nedenle mimari NGINX Ingress’e daha yakındır, aynı pod hem kaynakları izler hem de trafiği işler, Gateway başına proxy’leri dinamik olarak sağlamak yerine tek bir deployment izlenen namespace’teki tüm Gateway’leri yönetir; bu da tek hata noktası ve düşük izolasyon nedeniyle büyük ölçekte dayanıklılık sorunlarına yol açabilir

    • Seçim yaparken beklenen trafikle load test yapılması önerilir; özellikle Traefik’in performansına dair şikayetler duyulduğu için daha dikkatli olunmalıdır

    • NGINX Gateway Fabric

      • NGINX tabanlı F5’in resmi Gateway API uygulaması (NGF); güçlü conformance sunar ve son sürümlerde Gateway API 1.5 ile standart HTTPRoute filtreleri üzerinden CORS ve request/response header değiştirme desteği eklenmiştir
      • JWT ve OIDC kimlik doğrulama, cookie tabanlı session persistence, NGINX reload olmadan upstream güncelleme gibi bazı özellikler hâlâ NGINX Plus’a bağlıdır; bunlar yaygın API Gateway gereksinimleridir
      • Custom SnippetsPolicy ve SnippetsFilter ile oluşturulan yapılandırmanın çeşitli seviyelerine custom NGINX ayarları enjekte edilebilir; bu da mevcut NGINX Ingress’teki kapsamlı custom ayarları yeniden yazmadan geçişi kolaylaştırır
      • Custom RateLimitPolicy ile rate limiting desteklenir ancak bu local rate limiting’dir, yani durum NGINX data plane’de tutulur; birden fazla NGF replika çalıştırıldığında etkin sınır instance sayısına göre değişir, bu da kullanıcı bazında katı sınırlar koymayı zorlaştırır
      • NGINX’in kendi genişletme escape hatch’leri olarak hafif JavaScript ve Lua scripting, harici kimlik doğrulamayı devretmek için auth_request (Envoy ext_authz ve Traefik ForwardAuth’a benzer), custom C modülleri sunulur; ancak ext_proc tarzı harici servis tabanlı istek/yanıt değiştirme desteklenmez
      • NGF 2.0 ile mimari yeniden düzenlenerek control/data plane ayrımı ve çoklu Gateway kaynağı desteği getirildi; öncesinde mimari önemli bir endişe kaynağıydı

    • Cilium Service Mesh

      • Birçok küme CNI olarak Cilium kullanır; eBPF tabanlı, sidecar gerektirmeyen service mesh içinde Envoy Proxy tabanlı bir Gateway API uygulaması bulunur, böylece bileşen sayısı azaltılabilir ve teknoloji yığını sadeleştirilebilir
      • Ancak odak çoğunlukla Gateway API conformance üzerindedir; Gateway API dışındaki faydalı Envoy özellikleri birinci sınıf yapılandırma olarak sunulmaz; örneğin Envoy uzantıları ve eklentileri, IP allowlisting, JWT doğrulama, claim tabanlı authorization ve OIDC için birinci sınıf destek yoktur
      • Cilium’un mevcut Gateway API özelliklerinin yeterli olduğundan emin olunmadıkça, Envoy Gateway, kgateway veya Istio gibi daha zengin seçeneklere kıyasla genel amaçlı bir API Gateway olarak önerilmez

    • Kong

      • NGINX tabanlı popüler bir API Gateway’dir; Kong Operator hem Ingress hem de Gateway API’yi destekler
      • Başlıca endişe OSS stratejisidir; yeni açık kaynak Gateway sürümleri için prebuilt Docker image yayımlamayı durdurmuş görünüyor ve OSS image’lar 3.10 sürüm hattı civarında durmuş olabilir, bu da doğrudan build etme, patch uygulama, hardening ve bakım gerektirebilir
      • Bu adımın enterprise müşteri kaybını azaltmayla ilgili olduğuna dair kamuya açık spekülasyonlar vardır; kesinleşmiş bir gerçek olarak görülemez ancak OSS yönünün daha az öngörülebilir hissettirdiği söylenebilir
      • Bu nedenle enterprise lisansı satın almayacak veya OSS paketleme ve bakım yükünü kendisi üstlenmeye hazır olmayacak olanlara önerilmez

Summary

  • Kubernetes ingress kalıbının ilk dönemlerinden Gateway API çağına uzanan evrimi izler ve Gateway API protokolünün kendisini derinlemesine ele alır
  • GAMMA (Gateway API fikirlerini service mesh’e genişletme) ve Inference Extension (Kubernetes çıkarım iş yüklerini tanımlama ve optimize etme) bilerek kapsam dışında bırakılmıştır; bunlar ayrı derinlemesine inceleme gerektiren konulardır
  • Mevcut Gateway API uygulamaları ve seçim ölçütleri birlikte incelenir

İlgili okumalar

2 yorum

 
click 1 시간 전

Geçen yıl NGF’yi denemeye çalışmıştım ama Authorization header tabanlı kimlik doğrulaması oluşturmanın bir yolu olmadığı için envoy’a geçtiğimi hatırlıyorum.
envoy’dan ziyade nginx’i tercih ettiğim için, Gateway API’nin tamamı desteklenirse bir dahaki sefere NGF kullanmayı düşünüyorum
 
hmmhmmhm 2 시간 전

Görünüşe göre Envoy daha da öne çıkacak.