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.
📋 İçindekiler
-
# 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.
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ı.
Üçü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
Aşkın KILIÇYazar20+ 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.
AZ-305AZ-104AZ-500AZ-400DP-203AI-102İlgili Yazılar
İlginizi Çekebilir
Mehmet K.
Ingress-NGINX’in EOL sürecine girmesiyle birlikte bu geçiş kaçınılmaz oldu. Peki production ortamında karmaşık annotation yapıları olan Ingress tanımlarını Ingress2Gateway ne kadar başarılı çeviriyor, edge case’lerde sorun yaşıyor muyuz?
Hakan G.
Ingress-NGINX’in EOL sürecine girmesiyle bunu er ya da geç yapmak zorunda kalacaktık zaten. Peki mevcut annotation’larla heavily customize edilmiş Ingress tanımlarında dönüşüm ne kadar sorunsuz oluyor, büyük kayıplar oluyor mu?
Yorumlar kapalı.
2 comments