Ingress-NGINX Göçü: 5 Şaşırtıcı Davranış ve Çözümü
Mart 2026’da Kubernetes tarafında sessiz ama etkisi büyük bir şey oluyor: Ingress-NGINX yavaş yavaş sahneden çekiliyor. Kasım 2025’teki duyuruyu ilk okuduğumda ben de “tamam, Gateway API’ye geçeriz” diye düşündüm. Ama dur bir saniye — iş öyle — kendi adıma konuşayım — düz değil. Geçen ay bir finans kuruluşunda bu göçü planlarken şunu net gördüm: Ingress-NGINX’in yıllardır fark etmeden kullandığımız bazı varsayılanları var, ve bunları bilmeden taşınmak üretimde ufak bir sürpriz değil, baya kesinti çıkarabiliyor.
Bu yazıda, Ingress-NGINX’ten çıkmadan önce bilmeniz gereken beş davranışı kendi projelerimden örneklerle anlatacağım. Sadece “şu böyle çalışıyor” demeyeceğim; Gateway API’de bunu nasıl korursunuz, ya da bilinçli şekilde nasıl bırakılır, ona da değineceğim. Kısa kısa gideceğiz. Ama bazı yerlerde işler uzayacak, çünkü mevzu biraz kaygan.
Çok konuştum, örnekle göstereyim.
Önemli not: Ingress-NGINX ve NGINX Ingress (F5) iki ayrı proje. Bu yazıda sadece Kubernetes topluluğunun yönettiği Ingress-NGINX’ten bahsediyorum. İkisini karıştırmak çok yaygın bir hata — bizzat bir müşterimde yanlış controller’ın config’ını değiştirip saatlerce debug yapmıştık.
1. Regex Eşleşmeleri: Prefix Tabanlı ve Büyük/Küçük Harf Duyarsız
Bunu ilk gördüğümde “olmaz ya” dedim. Kısa sürdü o rahatlık. Diyelim ki sadece üç büyük harften oluşan path’leri, mesela /ABC gibi adresleri bir servise yönlendirmek istiyorsunuz; aşağı yukarı şöyle bir Ingress yazıyorsunuz:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: regex-match-ingress
annotations:
nginx.ingress.kubernetes.io/use-regex: "true"
spec:
ingressClassName: nginx
rules:
— host: regex-match.example.com
http:
paths:
— path: "/[A-Z]{3}"
pathType: ImplementationSpecific
backend:
service:
name: httpbin
port:
number: 8000
Mantık şu gibi geliyor: sadece /ABC, /XYZ eşleşsin. Peki neden /uuid de yakalanıyor? Çünkü Ingress-NGINX’te regex eşleşmesi prefix tabanlı çalışıyor ve büyük/küçük harfe de takılmıyor. Yanı /abc/some/other/path bile bu kuralın içine düşebiliyor. Evet, aynen öyle.
Bir dakika — bununla bitmedi.
2024 sonlarında bir e-ticaret projesinde bu yüzden saatlerce uğraştık (yanlış duymadınız). Ödeme callback URL’leri beklemediğimiz servislerde görünmeye başladı; sorun regex’in baştan sona birebir kontrol etmemesiymiş. Açık konuşayım, dokümanda vardı ama insan bazen gözünün önündekini görmüyor.
Gateway API’de Durum Ne?
Gateway API’deki RegularExpression path match tipi hayata geçirmea bağlı kalıyor. Ama Envoy tabanlı popüler seçeneklerde (Istio, Envoy Gateway, Kgateway) genelde tam eşleşme. Büyük/küçük harf duyarlılığı daha net geliyor. Bu ne demek? Aynı regex’i olduğu gibi taşırsanız, daha önce eşleşen bazı path’ler artık eşleşmeyebilir. İstemciler veya uygulamalar farkında olmadan /uuid gibi yollara trafik atıyorsa — ki atıyorlar — iş uzar.
Bence burada yapılacak en temiz şey şu: göçten önce mevcut Ingress-NGINX access log’larını tarayın ve gerçekte hangi path’lerin eşleştiğini görün. kubectl logs ile logları çekip regex kuralınıza düşen URL’leri listelemek yarım saatinizi alır,. Sizi uzun sürecek bir prod krizinden kurtarabilir.
2. Annotation Karmaşası: Gizli Varsayılanlar Her Yerde
Ingress-NGINX’in gücü annotation’lardan geliyor, ama işin tuhaf tarafı tam da burada başlıyor. Yüzlerce annotation var ve her biri başka bir varsayılanla yaşıyor. Mesela nginx.ingress.kubernetes.io/proxy-body-size kullanmadıysanız varsayılan değer 1m, yanı 1 megabayt. Dosya yükleyen bir endpoint’ınız varsa ve bunu Gateway API’ye taşırken bu detayı atladıysanız… hmm… sonuç çoğu zaman beklediğiniz gibi olmaz (yanlış duymadınız)
Logosoft’ta bir kamu kurumu projesinde timeout farkından doğan ilginç bir durum yaşamıştık. Ingress-NGINX’te proxy-read-timeout varsayılanı 60 saniye; ama bazı raporlama API’leri 90 saniye sürüyordu. Eski tarafta annotation açıkça verilmişti, yeni tarafta işe unutuldu. Sonuç? Raporlar ortada kaldı, kullanıcı da doğal olarak “sistem gitti” sandı.
kubectl get ingress -A -o json | jq '.items[].metadata.annotations' komutuyla hızlıca çıkarabilirsiniz. Eksik kritik annotation’ları bir spreadsheet’e yazın ve Gateway API karşılıklarını tek tek belirleyin.
3. Path Önceliklendirme: Uzun Path Her Zaman Kazanmaz
Şöyle ki, Şimdi işin biraz sınır bozucu tarafına geldik. Birden fazla Ingress aynı host’u paylaşıyorsa, Ingress-NGINX path önceliğini nasıl seçiyor? Çoğu kişi “uzun olan kazanır” diyor. Kısmen doğru, ama hepsi bu kadar değil.
Yanı, Sistem kabaca şöyle ilerliyor:
| Kriter | Öncelik Sırası | Gateway API Davranışı |
|---|---|---|
| Regex vs Non-regex | Non-regex önce değerlendirilir | İmplementasyona bağlı |
| Path uzunluğu (aynı tip) | Uzun path kazanır | Genelde aynı |
| Regex path’ler arası | Oluşturulma sırasına göre (ilk gelen kazanır) | Tanınmamış — riskli! |
| Aynı path, farklı Ingress | Namespace/isim sıralaması (alfabetik) | Conflict olarak işaretlenir |
Buna özellikle takıldım çünkü regex path’lerdeki önceliğin oluşturulma sırasına bağlı olması baya race condition kokuyor. 2023’te bir telekom ortamında iki ayrı ekip aynı host’a regex ekledi; hangisi önce yaratıldıysa trafik oraya gitti. Cluster yeniden kurulunca sıra değişti, trafik de yanlış yere kaydı. Bunu bulmamız dört saat sürdü, hiç abartmıyorum.
Gateway API’de bu belirsizlikler biraz daha az çünkü conflict durumları status tarafında açıkça görünüyor. Ama “biraz daha az” demek “neredeyse tamamen yok” demek değil; her uygulamaun kendine has köşeleri var.
4. Türkiye’deki Kurumsal Göç Gerçekleri
Bi saniye — Neyse, biraz da yerel taraftan bakalım. Türkiye’deki kurumsal şirketlerde Kubernetes kullanımı son 3-4 yılda ciddi arttı ama çoğu yerde Ingress-NGINX hâlâ “bir kere kuruldu, sonra kimse dokunmadı” modunda yaşıyor. Hele bir de bankacılık. Telekom tarafında gördüğüm tablo şu: production cluster’da 50-100 arası Ingress var, annotation’lar birbirini tutmuyor, dokümantasyon eksik, üstüne bir de “bunu kim ekledi?” sorusunun cevabı yok.
Böyle olunca Gateway API göçü teknik iş olmaktan çıkıp organizasyon işi hâline geliyor. Küçük bir startup için durum farklı tabi; beş on ingress varsa öğleden sonra toparlarsınız. Ama enterprise seviyede 200+ microservice’in routing kurallarını taşımak… işte burada tempo düşüyor biraz. Açık konuşayım, çoğu firma bunu “Mart 2026’ya kadar yaparız” diye erteliyor ama tarih hızla yaklaşıyor.
Bakın, Maliyet açısından bakınca yeni model ekstra cloud faturası çıkarmıyor gibi görünüyor. Ama göç sırasında oluşabilecek kesintiler, test ortamları. Mühendislik saati derken orta ölçekli bir ekip için 2-4 haftalık efor çıkabiliyor bana göre. TL bazında düşününce senior DevOps maliyeti artı olası downtime… hesabı sız yapın artık. Erken başlamak genelde daha ucuz oluyor.
5. SSL/TLS Termination ve Redirect Davranışları
Ne yalan söyleyeyim, Bence en riskli noktalardan biri bu olabilir. Ingress-NGINX varsayılan olarak HTTP’den HTTPS’e redirect yapıyor; bunu nginx.ingress.kubernetes.io/ssl-redirect: "true" ile yönetiyorsunuz ama çoğu kişi bunu ayrıca yazmıyor bile, çünkü default zaten true.
Peki Gateway API tarafına geçince ne oluyor? Çoğu hayata geçirmeda otomatik HTTP→HTTPS redirect yok; bunu açıkça tanımlamanız gerekiyor. Geçen ay bizzat yaşadım: bir müşteride göç sonrası mobil uygulama eski alışkanlıkla 301 bekliyordu ama Gateway API düz HTTP isteğini kabul edip 200 döndürdü. Güvenlik ekibi bunu görünce — haklı olarak — alarm verdi.
Ayrıca Ingress-NGINX’in HSTS header’ını da varsayılan olarak eklemesi çoğu kişinin aklına gelmiyor bile diyebilirim.
Düzeltelim:
Tuhaf ama, Ayrıca Ingress-NGINX’in HSTS (HTTP Strict Transport Security) header’ını da varsayılan olarak eklemesi sürpriz olabiliyor.
Daha net söyleyeyim:
Sıkça Sorulan Sorular
Ingress-NGINX ne zaman desteği kesiliyor?
Garip gelecek ama, Kubernetes topluluğu, Ingress-NGINX’i Mart 2026’da emekliye ayıracağını Kasım 2025’te duyurdu. Yanı bu tarihten sonra güvenlik yaması falan gelmiyor. Açıkçası Mart 2026’yı beklememek lazım — mümkünse göçünüzü önceden tamamlayın.
Geçiş sırasında downtime olur mu?
Doğru planlama ile sıfır downtime gayet mümkün. Hani aynı cluster’da hem Ingress-NGINX hem Gateway API controller’ı yan yana çalıştırabiliyorsunuz. DNS veya load balancer seviyesinde kademeli geçiş yaparsanız riski ciddi ölçüde azaltıyorsunuz (en azından benim deneyimim böyle). Ama plansız geçişte kesinti neredeyse kaçınılmaz — bence bu kısım en çok atlanan detay.
Ingress-NGINX annotation’larının Gateway API karşılığı var mı?
Çoğunun doğrudan karşılığı yok, maalesef. Gateway API daha standart bir yaklaşım sunuyor; mesela annotation yerine policy ve filter mekanizmaları kullanıyor. Her annotation için Gateway API hayata geçirmeunuzun belgelerine tek tek bakmanız gerekiyor — evrensel bir çeviri tablosu aslında mevcut değil.
Hangi Gateway API implementasyonunu seçmeliyim?
Envoy tabanlı çözümler (Istio, Envoy Gateway, Kgateway) şu an en olgun olanlar. Zaten Istio kullanıyorsanız doğal geçiş yolu orası. Kullanmıyorsanız Envoy Gateway başlangıç için oldukça hafif ve uygun — tecrübeme göre ilk geçişlerde fazla karmaşıklığa girmemek daha iyi. Yine de seçim tamamen mevcut altyapınıza ve ekibinizin deneyimine bağlı.
Evet, doğru duydunuz.
NGINX Ingress (F5) ile Ingress-NGINX aynı şey mi?
Hayır, kesinlikle değil. Ingress-NGINX Kubernetes topluluğunun projesi ve emekliye ayrılıyor. NGINX Ingress işe F5’in ticari ürünü, — itiraz edebilirsiniz tabi — o devam ediyor. İkisi de arka planda NGINX kullanıyor ama konfigürasyon, annotation’lar ve davranışları tamamen farklı. Yanı bu ikisini karıştırmayın — bence en yaygın yanılgı bu.
Kaynaklar ve İleri Okuma
Kubernetes Blog: Before You Migrate — Ingress-NGINX Behaviors
Kubernetes Gateway API Resmî Dokümantasyonu
Şimdi, ne yalan söyleyeyim, Ingress-NGINX Annotation Referansı
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.
3 comments