Ingress2Gateway 1.0: Ingress’ten Gateway API’ye Geçiş
Mart 2026’da Ingress-NGINX resmen emekliye ayrılıyor. Peki bu ne anlama geliyor? Şu: eğer hâlâ Ingress kaynaklarıyla yönettiğiniz bir Kubernetes ağ yapınız varsa, “bir gün geçeriz” dönemi kapandı. O gün artık geldi.
Ben bunu ilk duyduğumda — açık konuşayım — içim biraz sıkıştı. Çünkü yıllardır danışmanlık yaptığım projelerin büyük çoğunluğunda Ingress-NGINX annotation’larına dayalı yapılar kuruyorduk; CORS ayarları, path rewrite kuralları, backend TLS tanımlamaları… bunların hepsi o eski, tanıdık annotation satırlarına gömülüydü. Şimdi hepsini Gateway API’ye mi taşıyacağız? Evet. Ama neyse ki SIĞ Network ekibi bizi yalnız bırakmadı, en azından bu konuda.
Ingress-NGINX Neden Gidiyor?
Eh, Dur bir saniye, önce şunu anlatayım (kendi tecrübem). Ingress API, Kubernetes’in ilk yıllarında ağ trafiğini yönetmek için tasarlanmış basit bir arayüzdü. Basitti — ama işte tam da bu basitlik bir noktadan sonra yetersiz kalmaya başladı. Her Ingress controller’ı, özellikle Ingress-NGINX, kendi annotation’larını, ConfigMap’lerini, hatta zaman zaman kendi CRD’lerini de ekledi. Sonuç? Standart dışı, taşınması bir o kadar zor, birbirine benzemeyen yapılar.
2023’te bir e-ticaret müşterisinin altyapısını inceliyorduk. Adam 47 farklı Ingress kaynağı tanımlamış, her birinde 5-6 annotation var. Hangisi ne yapıyor? Belgelenmemiş. Test edilmemiş. “Çalışıyor, dokunma” felsefesiyle yıllarca öylece durmuş. İşte Ingress API’nın temel sorunu buydu — implementasyona bağımlı, ezoterik ayarlar.
Gateway API işe bambaşka bir şey sunuyor. Modüler. Genişletilebilir. Kubernetes-native RBAC ile doğrudan entegre. Yanı artık “bu annotation şu controller’da çalışır ama ötekinde çalışmaz” muhabbetiyle boğuşmuyorsunuz. Ha tabi, geçiş kolay mı? Değil. Ama en azından doğru yöne gidiyoruz, bu kadarı kesin.
Ingress2Gateway Nedir ve Neden 1.0 Önemli?
Ingress2Gateway, SIĞ Network tarafından geliştirilen bir göç asistanı. Dikkat edin, “otomatik dönüştürücü” demiyorum — çünkü ekip de bunu özellikle vurguluyor: bu bir asistan, tek tuşla her şeyi halleder diye beklenti yaratmayın kendinizde.
Peki ne yapıyor? Mevcut Ingress kaynaklarınızı alıyor, annotation’ları okuyor, Gateway API kaynaklarına çeviriyor. Çeviremediği şeyleri de size söylüyor. İşte bu son kısım bence en değerli yanı. Neyi kaybettiğinizi bilmek, neyi kazandığınızı bilmekten çok daha kritik çoğu zaman.
Şahsen, 1.0 öncesinde araç sadece 3 tane Ingress-NGINX annotation’ını destekliyordu. Üç. Yanı biraz şaka gibi, haklısınız. Ama 1.0 ile bu sayı 30’un üzerine çıktı; CORS, backend TLS, regex matching, path rewrite… Gerçek dünyada en sık kullanılan annotation’ların büyük çoğunluğu artık kapsama girmiş durumda.
Desteklenen Annotation Kategorileri
| Kategori | Örnek Annotation | Gateway API Karşılığı |
|---|---|---|
| CORS | nginx.ingress.kubernetes.io/enable-cors | HTTPRoute filter |
| Path Rewrite | nginx.ingress.kubernetes.io/rewrite-target | URLRewrite filter |
| Backend TLS | nginx.ingress.kubernetes.io/backend-protocol | BackendTLSPolicy |
| Redirect | nginx.ingress.kubernetes.io/ssl-redirect | RequestRedirect filter |
| Regex Matching | nginx.ingress.kubernetes.io/use-regex | RegularExpression path match |
Entegrasyon Testleri: Sadece YAML Karşılaştırması Değil
Şunu da söyleyeyim — bence 1.0’ın en iyi tarafı annotation desteği bile değil. Asıl mesele test altyapısı.
Ingress2Gateway ekibi sadece “YAML çıktısı doğru mu” diye bakmamış (şaşırtıcı ama gerçek). Gerçek bir cluster ayağa kaldırıyorlar, içine Ingress-NGINX controller kuruyorlar, yanına birden fazla Gateway API controller’ı ekliyorlar. Sonra Ingress kaynağını uyguluyorlar, ingress2gateway ile çevirip Gateway API kaynaklarını da apply ediyorlar. Runtime davranışını karşılaştırıyorlar — routing, redirect, rewrite, hepsini.
Bu önemli. Neyse, neden? Çünkü geçen yıl bir finans kuruluşunda tam olarak bu tür bir sorunla karşılaştık. YAML çıktısı güzeldi, hiçbir şey eksik görünmüyordu. Ama runtime’da rewrite kuralı beklediğimiz gibi çalışmadı. Neden? Ingress-NGINX’in default davranışı Gateway API’deki default davranıştan farklıydı. Bu tür sürprizleri ancak gerçek controller-level testlerle yakalayabilirsiniz, başka türlü değil.
Göç sürecinde en tehlikeli şey “çalışıyor gibi görünmek”tir. Ingress2Gateway 1.0’ın entegrasyon testleri, tam da bu görünmezlik sorununu çözmeye odaklanıyor.
Test Süreci Nasıl İşliyor?
Adım adım bakarsak:
- Ingress-NGINX controller ayağa kalkıyor (bence en önemlisi)
- Birden fazla Gateway API controller’ı başlatılıyor
- Annotation’lı Ingress kaynakları uygulanıyor
- ingress2gateway çeviriyi yapıyor ve çıktı apply ediliyor
- Her iki tarafın runtime davranışı karşılaştırılıyor
Bu süreç CI pipeline’a bütünleşik edilmiş durumda. Yanı her yeni annotation desteği eklendiğinde otomatik olarak doğrulanıyor. Bence bu yaklaşım, production’a taşınabilecek güvenilirlik seviyesini ciddi ölçüde artırıyor. Hmm, en azından benim gördüğüm kadarıyla öyle. Daha fazla bilgi için MSVC 14.51 ile C++23 Desteği: Sahadan Notlar yazımıza bakabilirsiniz.
Bildirım Sistemi ve Hata Yönetimi
Göç dediğin şey tek tuşla olan bir iş değil. Maalesef.
Dürüst olmak gerekirse, Her Ingress yapılandırmaunun birebir Gateway API karşılığı olmayabilir. Bazı annotation’lar çevrilemez. Bazıları kısmen çevrilir. Ve asıl önemli olan, sizin bunu bilmeniz. 1.0 öncesinde Ingress2Gateway’in bildirım sistemi — nasıl söylesem — biraz dağınıktı. Neyin eksik olduğunu, neyin sorunlu çıktığını, nerede müdahale etmeniz gerektiğini anlamak zordu.
Doğrusu, 1.0 ile birlikte bildirimler düzgün bir formata kavuşmuş. Çevrilemeyen konfigürasyonlar net biçimde (belki yanılıyorum ama) listeleniyor, yanında ne yapabileceğinize dair öneriler de var. Bu, özellikle büyük ekiplerde gerçekten işe yarıyor — geçen ay 200’den fazla Ingress kaynağı olan bir cluster üzerinde çalışıyorduk, ingress2gateway’i çalıştırdığımızda 23 kaynak için uyarı aldık, her birinin yanında açıklama vardı ve hangi kaynakları manuel müdahaleyle taşımamız gerektiğini hemen gördük.
Pratikte Nasıl Kullanılıyor?
Gelelim asıl meseleye. Teoriyi bırakıp sahaya inelim.
Bir şey dikkatimi çekti: Kurulum oldukça basit. Go modülü olarak ya da doğrudan release binary’si ile kurabilirsiniz: .NET ve.NET Framework Nisan 2026 Güvenlik Yamaları yazımızda bu konuya da değinmiştik. GitHub Pages ile Ücretsiz Site Kurulumu: Tam Rehber yazımızda bu konuya da değinmiştik.
# Kurulum
go install github.com/kubernetes-sigs/ingress2gateway@v1.0.0
# Mevcut Ingress kaynaklarını çevir
ingress2gateway print --providers ingress-nginx \
--input-file my-ingress.yaml \
--output-file gateway-api-output.yaml
# Veya doğrudan cluster'dan oku
ingress2gateway print --providers ingress-nginx \
--all-namespacesAçık konuşayım, Çıktıyı aldıktan sonra hemen apply etmeyin. Lütfen. Önce gözden geçirin. Bildirimleri okuyun. Staging’de test edin. Sonra production’a taşıyın. Az önce “hemen çevirin” diyecektim neredeyse ama hayır — acele etmek bu işte çoğu zaman sorun çıkarıyor, bizzat gördüm.
Küçük Ekip vs Enterprise: Fark Nerede?
Vallahi, Küçük bir startup’ta belki 5-10 Ingress kaynağınız vardır. Bunları elle de çevirebilirsiniz açıkçası. Ama ingress2gateway yine de işe yarıyor, çünkü annotation-to-filter eşleştirmesini ezberlemek zorunda kalmıyorsunuz.
Enterprise tarafında durum çok farklı. Yüzlerce Ingress kaynağı, onlarca namespace, farklı ekiplerin birbirinden kopuk annotation kalıpları (evet, doğru duydunuz). Burada ingress2gateway olmadan göç yapmak — yanı, ciddi cesaret ister. 2024’te bir bankacılık projesinde Ingress’ten Gateway API’ye geçişi elle yapmaya çalışan bir ekip gördüm; 3 ay sürdü ve production’da 2 kez downtime çıktı. Araç kullanmak zaman kazandırıyor, daha da önemlisi hata riskini ciddi ölçüde azaltıyor. Bu konuyla ilgili .NET Agent Skills: Üç Yöntem, Tek Sağlayıcı yazımıza da göz atmanızı tavsiye ederim.
Kubernetes ekosistemine dair güncel gelişmeleri takip ediyorsanız, Kubernetes 1.36 Ön İzleme: Neler Geliyor, Neler Gidiyor? yazımda 1.36 ile gelen değişikliklere de göz atmanızı öneririm.
Eksik Kalan ve Beni Hayal Kırıklığına Uğratan Şeyler
Güzel, güzel de… Her şey pembe değil. Birkaç noktada bu 1.0 sürümü beklentimi karşılamadı.
Bunu yaşayan biri olarak söyleyeyim, Birincisi şu: 30+ annotation desteği var. Ingress-NGINX’in toplam annotation sayısı 80’in üzerinde. Yanı hâlâ eksik kalan çok şey var. Rate limiting, custom headers gibi bazı popüler annotation’lar henüz desteklenmiyor. Kağıt üstünde “1.0 stable” yazıyor ama feature coverage açısından daha gidilecek yol var.
İkincisi: araç şu an sadece Ingress-NGINX’i gerçek anlamda destekliyor. Traefik, HAProxy, Kong gibi diğer Ingress controller’lar için destek ya yok ya çok kısıtlı. Bir arkadaşım Kong Ingress Controller’dan geçiş yapmaya çalıştı — ingress2gateway annotation’ların neredeyse hiçbirini tanımadı. 3 günlük iş 2 haftaya çıktı. Daha fazla bilgi için ChatGPT ile Araştırma: Search ve Deep Research Rehberi yazımıza bakabilirsiniz.
Üçüncüsü: dry-run modu var ama GUI yok. Her şey CLI. Büyük ekiplerde, özellikle Kubernetes’e çok hâkim olmayan DevOps mühendisleri için bir web arayüzü ya da en azından interaktif bir TUI olsa çok daha kullanışlı olurdu. Bence bu açık nokta.
Stratejik Tavsiyelerim
Bakın, bu göç kaçınılmaz. Mart 2026 kapıda. Ertelemenin artık bir anlamı yok. Ama panik yapmanın da anlamı yok. Şöyle bir yol haritası öneriyorum:
- Envanter çıkarın: Tüm Ingress kaynaklarınızı listeleyin. Hangi annotation’lar kullanılıyor? Kaçı ingress2gateway tarafından destekleniyor?
- Staging’de çalıştırın: ingress2gateway’i önce staging cluster’ınızda deneyin. Bildirimleri dikkatlice okuyun.
- Manuel müdahale gereken yerleri belirleyin: Çevrilemeyen annotation’lar için alternatif Gateway API çözümleri araştırın.
- Kademeli geçiş yapın: Tüm Ingress’leri tek seferde değil, namespace namespace taşıyın.
- Paralel çalıştırın: Bir süre hem Ingress hem Gateway API kaynaklarını birlikte ayakta tutun. Davranış farkı çıkıyor mu gözlemleyin.
Ha bu arada, GitHub Actions’ta 50 Yeniden Çalıştırma Sınırı: Sahada Ne Değişiyor? yazısında da bahsettiğim gibi, CI/CD pipeline’larınızda da bu geçişe uygun değişiklikler yapmanız gerekecek. Gateway API kaynaklarının doğrulamasını pipeline’a eklemeyi de unutmayın.
Sıkça Sorulan Sorular
Ingress2Gateway mevcut Ingress kaynaklarımı siler mi?
Hayır, bana kalırsa silmez. Araç sadece okuma yapar ve yeni Gateway API YAML dosyaları üretir. Mevcut Ingress kaynaklarınız olduğu gibi kalır. Sız hazır olduğunuzda kendiniz kaldırırsınız.
Gateway API’ye geçince Ingress-NGINX controller’ı hemen kaldırmalı mıyım?
Bence acele etmeyin. Bir süre ikisini paralel çalıştırın (yanlış duymadınız). Davranış eşdeğerliğini doğruladıktan sonra eski Ingress controller’ı kaldırabilirsiniz. Ben genelde 2-4 hafta paralel çalıştırma öneriyorum (en azından benim deneyimim böyle)
Ingress2Gateway hangi Gateway API controller’larını destekliyor?
Araya gireyim: Araç controller-agnostic çıktı üretiyor — yanı standart Gateway API kaynakları oluşturuyor. Envoy Gateway, Istio, Cilium, NGINX Gateway Fabric gibi herhangi bir uyumlu controller ile kullanabilirsiniz.
Annotation’larım desteklenmiyorsa ne yapmalıyım?
Ingress2Gateway çeviremediği annotation’lar için bildirım veriyor (şaşırtıcı ama gerçek). Bu annotation’ların Gateway API karşılığını manuel olarak yazmanız gerekiyor. Bazı durumlarda ExtensionRef veya Policy API’leri kullanarak karşılık bulabilirsiniz.
Ingress2Gateway’i CI/CD pipeline’ıma entegre edebilir mıyım?
Evet, CLI tabanlı bir araç olduğu için pipeline’a kolayca eklenebilir. Hele bir de dry-run modunda çalıştırıp çıktıyı review adımına aktarmak mantıklı bir yaklaşım. Neden önemli bu? Ama otomatik apply etmeyin — mutlaka bir onay adımı koyun.
Kaynaklar ve İleri Okuma
Ingress2Gateway 1.0 Release — Kubernetes Blog
Peki, bir şey dikkatimi çekti: Kubernetes Gateway API Resmî Dokümantasyonu
Ingress2Gateway GitHub Repository
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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
2 comments