ingress-nginx Mart 2026'da emekliye ayrılıyor, Kubernetes kullanıcılarını Gateway API'ye yönlendiriyor

ingress-nginx halefi olmadan yavaş yavaş kapanıyor

Kubernetes projesi, ingress-nginx'in Mart 2026'da emekliye ayrılacağını duyurdu; bu tarihten sonra controller artık patch veya güncelleme almayacak. Bir halef isimlendirilmedi; öneri Gateway API'ye geçiş yapmak. dev.to'da yayınlanan bir geçiş rehberine göre bunun nedeni maintainer eksikliği — yıllarca proje fiilen bir veya iki kişinin boş zamanlarında sürdürdüğü bir çabaydı.

Makale, emeklilik duyurusunun ardından Gateway API topluluğuyla iş birliği içinde InGate adlı bir yedek controller planlandığını, ancak hiç katkıcının öne çıkmadığını ve InGate'in de emekliye ayrıldığını açıklıyor. Yazar, duyurunun neden bir yenisini isimlendirmediği konusunda açık sözlü: isimlendirilecek uygulanabilir bir proje yoktu.

Mevcut dağıtımlar bir gecede kırılmayacak. Helm chart'ları ve container imajları kullanılabilir kalacak, ancak güvenlik düzeltmeleri gelmeyi kesecek. Yeni zafiyetler bulunduğunda yamasız kalacakları için sistem çalışmaya devam ederken, düzeltilmemiş açık sessizce büyüyecek.

Gateway API bir yazılım değil, bir spesifikasyon

En büyük kavramsal değişim, Gateway API'nin bir program değil bir Kubernetes spesifikasyonu olması. Ingress çağında bir Ingress manifest'i uygulamak işe yarıyordu çünkü neredeyse evrensel implementation olan ingress-nginx zaten kurulu durumdaydı ve spesifikasyon ile implementation fiilen aynı şeydi. Kurulu bir Gateway controller'ı olmayan bir cluster'a uygulanan bir HTTPRoute hiçbir şey yapmaz. Dolayısıyla Gateway API'ye geçmek, bir implementation seçip kurmak anlamına geliyor; eskiden örtük olan bir kararı açık hale getiriyor.

Çok fazla implementation, varsayılan yok

Seçenekler çok sayıda. Yalnızca Envoy tabanlı aile içinde makale Envoy Gateway, kgateway, Istio, Contour ve Cilium'u listeliyor; bunun dışında Traefik, Kong ve NGINX Gateway Fabric ile her bulut sağlayıcısının kendi teklifi var. Hepsi Gateway API uyumluluğu iddia ediyor, ancak dev.to yazısı bunların birbirinin yerine geçebilir olmadığının üç nedenini veriyor.

Birincisi, uyumluluk seviyeleri değişiyor: Gateway API özellikleri Core, Extended ve Implementation-specific katmanlarına bölünmüş durumda ve uyumluluk iddiası için yalnızca Core desteği gerekiyor. İkincisi, production sistemlerinin gerçekten ihtiyaç duyduğu özellikler — kimlik doğrulama, rate limiting, circuit breaking — genellikle Extended veya Implementation-specific alanında yaşıyor ve Envoy Gateway'in SecurityPolicy CRD'si ya da Istio'nun AuthorizationPolicy'si gibi vendor kaynaklarıyla ifade ediliyor. Bu kaynaklardan birini yazmak sizi o implementation'a kilitliyor. Üçüncüsü, artık bir varsayılan yok: ingress-nginx eskiden ilk tercih edilen seçenekti ve şimdi her ekip aynı anda, yerleşik bir cevap olmadan aynı kararla karşı karşıya.

Ana seçenekler nasıl karşılaştırılıyor

Makale dört implementation'ı karşılaştırıyor. Envoy Gateway, bir Envoy data plane'i iyi geçiş kolaylığı, mükemmel genişletilmiş özellik kapsamı ve CNCF incubating projesi olarak güçlü momentumla birleştiriyor. Istio, east-west trafik kontrolü ve sidecar injection dahil tam service mesh desteği sunan tek seçenek; mesh stack'i bir ön koşul olduğu için geçiş kolaylığı açısından orta dereceli ve CNCF graduated olup mükemmel momentumda. Traefik kendi data plane'ini çalıştırıyor, temel yönlendirmeyi iyi yapıyor ve iyi bir momentum sergiliyor. NGINX Gateway Fabric, ingress-nginx ile aynı nginx data plane'ini paylaştığı için geçiş kolaylığı açısından mükemmel derecelendirilmiş durumda, ancak daha düşük bir sürüm sıklığına ve orta düzey momentum sahip.

Yazar bilinçli olarak bir öneri yapmıyor ve doğru cevabın halihazırda bir service mesh çalıştırıp çalıştırdığınıza, bir annotation yeniden yazımının ne kadar maliyetli olacağına ve ekibinizin Envoy ile operasyonel deneyime sahip olup olmadığına bağlı olduğunu savunuyor.

Annotation'ları üç kategoriye ayırın

Makalenin önerdiği pratik yöntem, üç kategoriye ayrılmış bir annotation envanteri. Kategori A, doğrudan standart Gateway API kaynaklarına geçen annotation'ları kapsıyor; path rewrite'lar örnek olarak işleniyor; /api(/|$)(.*) gibi bir ingress-nginx regex deseni ve /$2 rewrite-target'ı, eşdeğer standart HTTPRoute yapılandırmasına karşılık geliyor. Kategori B, external auth ve rate limiting gibi standart spesifikasyonda ifade edilemeyen özellikleri kapsıyor ve Implementation-specific kaynaklar gerektiriyor. Kategori C, annotation annotation değil satır satır değerlendiriliyor: tek bir configuration-snippet, Kategori A'ya ait satırlarla Kategori B gerektiren satırları karıştırabilir.

Makaleye, öncesi ve sonrası manifest'ler ile doğrulama script'leri eşlik ediyor ve bunlar herkese açık bir depoda bulunuyor. Implementation-specific örnekler için Envoy Gateway ve Istio seçildi çünkü uzantıları en geniş kapsamı sunuyor; Traefik ve NGINX Gateway Fabric ise temel yönlendirme yapabilse de daha az olgun vendor uzantılarına sahip.

Neden önemli

ingress-nginx, Kubernetes'te HTTP trafiği sunmak için örtük varsaylandı; emekliliği bu varsayılanı kaldırıyor ve ingress yönlendirmesini açık bir mimari karara dönüştürüyor. Yerinde kalmak istikrarlı bir seçim değil, çünkü güvenlik patch'lerinin sonu, dokunulmamış bir dağıtımı yavaşça büyüyen bir yükümlülüğe dönüştürüyor. Ve ekiplerin en çok güvendiği özellikler — kimlik doğrulama ve rate limiting gibi — çoğunlukla Gateway API Core spesifikasyonunun dışında yer aldığından, ilk implementation seçimi genellikle yapışkan oluyor. Annotation'larını şimdi envanterleyip standart olanı vendor'a özgü olandan ayıran ekipler, bu seçimi kazara bir lock-in devralmak yerine bilinçli olarak yapabilir.