Ingress’ten Gateway API’ye Geçiş: 1.0 Rehberi

Kubernetes networking tarafında uzun süredir beklenen o kırılma noktasına geldik. Ingress-NGINX için emeklilik takvimi Mart 2026 diye açıklandı ve artık “geçiş yapacak mıyız?” sorusu yavaş yavaş kenara çekilip “bunu nasıl güvenli yapacağız?” sorusuna dönüştü. Ben bunu ilk duyduğumda, açık konuşayım, biraz tedirgin oldum. Çünkü yıllardır Ingress üstüne kurulmuş onlarca production ortamı yönettim; annotation’larla, ConfigMap’lerle, bazen de tuhaf workaround’larla ayakta duran yapılar var, bunları bir gecede söküp yeniden kurmak kolay değil (inanın bana)

Evet.

Aslında — hayır dur, daha doğrusu, Neyse ki SIG Network ekibi boş durmamış. Ingress2Gateway aracının 1.0 sürümü çıktı. Bu sefer “eh işte” seviyesini geçip gerçekten kullanılabilir tarafa gelmiş gibi duruyor. Daha önceki sürümlerini ben de kurcalamıştım; sadece 3 annotation destekliyordu, yani pratikte eli kolu bağlıydı, ama şimdi 30’dan fazla annotation desteği var. Bu fark baya iş görüyor.

Gateway API Nedir, Neden Ingress Yetmiyor?

Şimdi bakın, Ingress API’nin olayı başta baya iyiydi. Bir YAML yazıyorsunuz, path bazlı routing veriyorsunuz, arkaya service bağlıyorsunuz — tamamdır. Ama iş büyüyünce tablo değişiyor. CORS lazım oluyor, annotation ekliyorsunuz. Backend TLS istiyorsunuz, bir başka annotation çıkıyor karşınıza. Regex path rewrite gerekiyor, yine annotation. Bir de bunların her Ingress controller’da aynı davranmadığını düşünün… İşte orada insanın kafası dağılıyor.

Gateway API ise biraz daha derli toplu bir yol açıyor. Gateway, HTTPRoute, GRPCRoute gibi ayrı resource’larla çalışıyorsunuz; ilk bakışta fazla parçalı gibi geliyor ama durun bir saniye — asıl rahatlık da burada çıkıyor. Kubernetes-native RBAC desteği var,. Platform ekibi Gateway tarafını tanımlarken uygulama ekipleri kendi HTTPRoute’larını yönetebiliyor. Bu ayrım özellikle enterprise ortamlarda baya iş görüyor; hani şu “herkes her şeye erişiyor” düzenini yaşamış olanlar ne demek istediğimi hemen anlar.

Size bir şey söyleyeyim, Geçen yıl bir finans kuruluşunda tam olarak bununla uğraştık. DevOps ekibi Ingress resource’larını yönetiyordu ama uygulama ekipleri sürekli “şu annotation’ı ekleyin”, “bu path’i değiştirin” diye ticket açıyordu; süreç uzadıkça uzuyordu. Açık konuşayım, kimse mutlu değildi (ne yazık ki klasik hikaye). Gateway API’ye geçince her ekip kendi HTTPRoute’unu yönetmeye başladı, aradaki gidip gelmeler azaldı ve ticket sayısı %60 düştü — abartmıyorum.

Ingress2Gateway 1.0: Gerçekten Ne Değişti?

Bunu yaşayan biri olarak söyleyeyim, Daha önceki sürümleri kullanmayı denediyseniz hayal kırıklığına uğramış olabilirsiniz. Ben 2024’te 0.3 versiyonunu bir test ortamında denemiştim, sadece basit host ve path kurallarını çevirebiliyordu. CORS, TLS, rewrite gibi şeyler? Hiçbiri yoktu. E o zaman ne işe yarıyor ki?

Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.

Burada, bunu yaşayan biri olarak söyleyeyim, 1.0 ile durum bayağı farklı. İşte öne çıkan gelişmeler:

Özellik	Önceki Sürümler	1.0 Sürümü
Desteklenen Ingress-NGINX annotation sayısı	3	30+
CORS desteği	Yok	Var
Backend TLS	Yok	Var
Regex path matching	Yok	Var
Path rewrite	Yok	Var
Controller-level entegrasyon testleri	Kısıtlı	Kapsamlı
Bildirim ve hata raporlama	Ham, kafa karıştırıcı	Temiz, aksiyon odaklı

30 annotation desteği deyince “hepsini karşılıyor mu?” diye sorabilirsiniz. Hayır. Ingress-NGINX’in yüzlerce annotation’ı var ve bazıları o kadar niş ki Gateway API’de doğrudan karşılığı yok. Ama en çok kullanılan 30 tanesini kapsıyor ve bu, çoğu kurumsal ortam için yeterli.

Entegrasyon Testleri: İşin Ciddiye Bindiği Yer

Bakın, beni en çok çarpan taraf annotation desteği değildi. Test altyapısıydı. Çünkü YAML çevirmek kolay gibi duruyor, hatta ilk bakışta “tamam işte” diyorsunuz, ama asıl mesele çevrilen YAML’ın sahada aynı şeyi yapıp yapmadığı (yanlış duymadınız)

Ingress2Gateway 1.0’ın test süreci şöyle akıyor:

1. Gerçek bir Ingress-NGINX controller ayağa kaldırılıyor
2. Birden fazla Gateway API controller’ı da başlatılıyor
3. Implementation-specific annotation’ları olan Ingress resource’ları apply ediliyor
4. ingress2gateway ile çeviri yapılıp Gateway API manifest’leri oluşturuluyor (bence en önemlisi)
5. Her iki tarafın runtime davranışı karşılaştırılıyor — routing, redirect, rewrite…

Yani mesele sadece “YAML doğru mu?” değil. Asıl soru şu: aynı — kendi adıma konuşayım — trafik akıyor mu, aynı yönlendirme oluyor mu, aynı yerde mi patlıyor? Peki neden? Çünkü kağıt üstünde düzgün görünen şeyler, production’a çıkınca bazen ufak bir detay yüzünden saçma sapan sürprizler çıkarıyor. Geçen ay bir e-ticaret projesinde Ingress’ten Gateway API’ye geçiş yaparken benzer bir şey yaşadım; path rewrite kuralındaki minicik fark yüzünden ödeme sayfası 404 dönmeye başladı, hani insan önce kendinden şüphe ediyor ya, öyle bir an.

Eğer bu tarz entegrasyon testleri önceden koşturulsaydı, o sorun büyük ihtimalle production’a hiç çıkmazdı. Bu kadar basit.

Ingress2Gateway bir “tek tuşla geçiş” aracı değil, bir geçiş asistanı. Çeviremediği ayarları size söylüyor ve ne yapmanız gerektiğini öneriyor. Bu farkı anlamak çok kritik.

Pratik Kullanım: Nasıl Başlanır?

Kurulum aslında bayağı rahat. Go ile yazılmış bir CLI aracı var, isterseniz go install ile kuruyorsunuz, isterseniz binary indirip geçiyorsunuz; yani işin o kısmı uzamıyor,. Yine de ilk çalıştırmada bir bakıp çıkmakta fayda var.

# Kurulum
go install github.com/kubernetes-sigs/ingress2gateway@v1.0.0
# Mevcut Ingress resource'larını çevir
ingress2gateway print --providers ingress-nginx \
--input-file my-ingress.yaml \
--output-file gateway-api.yaml
# Cluster'daki tüm Ingress resource'larını çevir
ingress2gateway print --providers ingress-nginx \
--all-namespaces

Ha bu arada, print komutu sadece çıktıyı gösteriyor, doğrudan apply etmiyor. İyi de oluyor açıkçası. Önce ne ürettiğine bakıyorsunuz, notification’ları gözden geçiriyorsunuz, eksik ya da çevrilemeyen yerleri not alıyorsunuz, sonra siz bilinçli şekilde uyguluyorsunuz; production tarafında “ben bunu ne ara bastım” dedirten kazaları biraz olsun azaltıyor.

Notification Sistemi

1.0 sürümünde en hoşuma giden kısımlardan biri bu bildirim işi oldu. Mesela bir annotation’ın birebir karşılığı yoksa size öyle dümdüz “yok” demiyor; “Bu annotation Gateway API’de doğrudan yok, şunu düşünebilirsiniz” gibi daha işe yarar bir şey söylüyor. Önceki sürümlerde mesajlar biraz ham kalıyordu, şimdi ise hem okunuyor hem de insanın ne yapacağını anlamasına yardım ediyor.

Küçük bir startup için bu uyarılar çoğu zaman yeterli geliyor, okursunuz ve yol alırsınız. Ama enterprise tarafında 200+ Ingress resource varsa iş değişiyor, orada tek tek bakmak yerine bunu CI/CD pipeline’a bağlayıp raporu otomatik toplamak daha mantıklı oluyor; iyi haber şu ki çıktı JSON olarak da alınabiliyor, (bu konuda ikircikliyim). O kısımda eliniz kolunuz bağlı değil.

Türkiye’deki Kurumsal Ortamlarda Durum

Şimdi gelelim Türkiye tarafına. Logosoft’ta epey kurumsal müşteriyle çalışıyorum ve açık konuşayım, sahada gördüğüm tablo biraz böyle: şirketlerin önemli bir kısmı hâlâ Ingress-NGINX ile yürüyor. Gateway API diye bir gündem var, evet, ama işin mutfağında aksiyon alan sayısı şaşırtıcı derecede az. Neden mi?

İtiraf edeyim, Birkaç sebep üst üste geliyor. Birincisi, o meşhur “çalışıyorsa dokunma” yaklaşımı; bunu hepimiz biliyoruz, hatta bazen hak veriyorsunuz, çünkü sistem oturmuşsa kimse elini sürmek istemiyor. İkincisi, Gateway API controller seçimi hiç öyle tek bakışta çözülmüyor (Envoy Gateway mı, Cilium Gateway API mı, NGINX Gateway Fabric mı?), hepsinin artısı var, eksisi var, bir de üstüne ekiplerin alışkanlıkları binince karar iyice uzuyor. Üçüncüsü de para meselesi; geçiş projesi dediğiniz şey sadece teknik iş değil, aynı zamanda insan saati demek. Türkiye’de BT bütçeleri malum, çok rahat nefes almıyor. Kubernetes v1.36 Neler Getiriyor: Büyük Değişiklikler yazımızda bu konuya da değinmiştik.

Ama burada küçük bir dipnot düşeyim: Mart 2026 deadline’ı geldi bile sayılır. Ingress-NGINX artık güvenlik yamaları bile alamayabilir, bu da özellikle finans ve sağlık gibi sektörlerde pek iç açıcı bir senaryo değil. İşte, geçen ay bir telekom müşterisinde tam bunu anlattım — “Şu an sorunsuz çalışıyor olabilir ama 6 ay sonra bir CVE çıkarsa ve yama gelmezse ne yapacaksınız?” dedim; toplantının havası bir anda değişti ve ardından geçiş projesi onaylandı. Bazen tek soru yeterli oluyor. SQL’e Dönüşün İlk Günü: Konsantrasyon, Notlar, İnat yazımızda bu konuya da değinmiştik.

Evet, doğru duydunuz. Daha fazla bilgi için Ddev’e Aljibe Eklemek: Kurulu Projede Sürprizler yazımıza bakabilirsiniz.

Geçiş Stratejisi: Adım Adım Ne Yapmalı?

İlk iş olarak şunu yapın. Ben kendi projelerimde de hep böyle başladım,. En başta neyin nereye bağlı olduğunu görmeden geçiş planı çıkarmak biraz sallama oluyor, hele cluster büyüdüyse iş iyice karışıyor.

1. Envanter Çıkarın

Önce cluster’ınızdaki tüm Ingress resource’larını listeleyin. Hangi annotation’lar kullanılıyor, kaç tanesinde custom ConfigMap var, hangileri eski kalmış, hangileri hâlâ trafik alıyor; bunları bilmeden sağlıklı bir geçiş yapamazsınız. Basit bir kubectl get ingress --all-namespaces -o yaml ile başlayabilirsiniz. Büyük ortamlarda bunu bir script ile parse etmek daha mantıklı geliyor, yoksa gözle bakıp kaçırdığınız detay sonra geri dönüp sizi ısırıyor. GA4’ü Bırakıp Next.js + Supabase’e Geçmek: Neden? yazımızda bu konuya da değinmiştik.

2. Gateway API Controller Seçin

Burada karar biraz kritik. Eğer ortamda zaten — en azından ben öyle düşünüyorum — Envoy varsa Envoy Gateway tarafı baya iş görüyor; Cilium CNI kullanıyorsanız Cilium’un Gateway API desteği de fena değil, hatta bazı ekipler için yeterince rahat bile olabilir. NGINX tarafına alışkınsanız NGINX Gateway Fabric’e bakabilirsiniz — ama küçük bir not düşeyim, bu ürün Ingress-NGINX ile aynı şey değil, isim benziyor diye karıştırmayın.

Bunu biraz açayım.

Bence küçük bir ekipseniz Envoy Gateway ile başlamak daha az yorar, community tarafı canlı ve dokümantasyon da idare eder. Kurumsal tarafta ise iş biraz değişiyor; zaten Istio gibi bir service mesh kullanıyorsanız Gateway API desteği native geliyor,. Ekstra kıvrım yapmadan ilerleyebiliyorsunuz. Tabii her senaryoda aynı sonuç çıkmaz, ama başlangıç noktası olarak kötü durmuyor.

3. Ingress2Gateway ile Çeviri Yapın

Aracı çalıştırın, çıkan sonucu tek tek inceleyin, notification’ları atlamayın. Çevrilemeyen konfigürasyonlar olacak, buna hazırlıklı olun; o kısımlar için manuel plan çıkarın ve işi staging ortamında mutlaka deneyin. Şey gibi düşünün: araç size yol gösteriyor ama direksiyona tamamen oturtmuyor.

Aslında burada önemli bir detay var — dur bir saniye — staging ortamı dediğimiz yer production’a mümkün olduğunca yakın olmalı. “Staging’de 5 Ingress var, production’da 50” diye test yaparsanız pek anlamlı olmaz; sonuç güzel görünür. Gerçek hayatta patlar. Yukarıda bahsettiğim o olay tam da bu işte.

Peki neden?

4. Paralel Çalıştırma

Hemen Ingress’i söküp atmayın. Bir süre hem (söylemesi ayıp) Ingress hem Gateway API tarafını paralel çalıştırın, trafiği de yavaş yavaş yeni tarafa kaydırın; böylece risk azalıyor ama evet, maliyet biraz artıyor çünkü iki controller aynı anda dönüyor. Küçük ekiplerde bu yöntem bazen fazla lüks kaçabiliyor, o durumda canary deployment daha mantıklı bir çıkış yolu olabiliyor (şaşırtıcı ama gerçek) Kubernetes v1.36 ile Gelen Değişiklikler ve Notlarım yazımızda bu konuya da değinmiştik.

Evet.

Dikkat Edilmesi Gereken Edge Case’ler

Kağıt üstünde her şey temiz görünüyor, ama pratikte iş biraz dağılıyor. Birkaç örnek vereyim, çünkü insan tam burada sürpriz yiyor: default backend davranışı var, regex path’ler var, bir de session affinity ile rate limiting meselesi çıkıyor; yani teori başka, sahada bambaşka (inanın bana)

• Default backend davranışı: Ingress-NGINX’te default backend tanımlamadığınızda 404 döner. Gateway API’de bu davranış controller’a göre değişebilir. Bunu test edin. — ciddi fark yaratıyor
• Regex path’ler: Ingress-NGINX PCRE regex kullanır. Gateway API’deki regex desteği implementasyona bağlı ve bazı pattern’ler farklı çalışabilir.
• Session affinity: Cookie-based session affinity Ingress-NGINX’te annotation ile yapılır. Gateway API’de henüz standart bir yol yok — çoğu implementation kendi CRD’sini kullanıyor.
• Rate limiting: Bu da Gateway API’de standart değil. Ingress-NGINX annotation’larından bire bir çeviri mümkün olmayabiliyor.

İlk denememde tam da regex path tarafında patladım. Bir müşteride ~* ^/api/v[0-9]+/ gibi bir pattern vardı; çeviri sonrası Gateway API tarafında match etmedi, şaşırdım açıkçası. Sebebi de aslında basitmiş: kullandığımız Gateway controller RE2 regex engine kullanıyordu, PCRE’deki bazı syntax’ları desteklemiyordu (hani küçük görünen detaylar olur ya, işte onlardan biri). Çözüm olarak pattern’i sadeleştirdik, sonra akış yerine oturdu.

Ve işler burada ilginçleşiyor.

Eğer bu konuyla birlikte Kubernetes ortamlarında test süreçlerini nasıl daha düzgün hale getirebileceğinizi de kurcalıyorsanız, Kubernetes’te Testi Sola Çekmek: Geçici Ortamlar yazımıza da göz atın derim. Faydalı olabilir.

Evet.

Bazen tek fark bir regex oluyor.

Neyse uzatmayalım.

Maliyet ve Zaman Tahmini

Herkesin aklındaki soru bu: “Bu geçiş ne kadar sürer, ne kadara patlar?” Cevabı tek satırda vermek zor, açık konuşayım. Kendi gördüklerimden bir çerçeve çizebilirim, çünkü işin içinde sadece YAML yok, test var, geri dönüş var, bir de beklenmedik küçük sürprizler var.

10-20 Ingress resource’ı olan küçük bir ortamda, Ingress2Gateway ile çeviri, test ve canlıya alma işi genelde 1-2 haftayı buluyor. Tek kişiyle döner. Ama 100+ Ingress resource’ı olan enterprise tarafta tablo değişiyor; en az 1-2 ay gidiyor, üstüne 2-3 kişilik ekip gerekiyor, çünkü custom annotation’lar, özel ConfigMap’ler. Edge case’ler insanın önüne durup dururken çıkıyor.

Bi saniye — Azure tarafında çalışıyorsanız, AKS’nin Gateway API desteğine de bakın derim. Application Gateway for Containers (AGC) artık Gateway API ile uyumlu geliyor. Managed olduğu için operasyon yükünü baya azaltıyor; hani gece yarısı pod bakımıyla uğraşmak istemeyen ekipler için fena değil. TL bazında düşününce de AGC’nin saatlik maliyeti yaklaşık 0,5-1 TL civarında dolaşıyor — Ingress-NGINX’i kendi pod’larınızda çalıştırırken oluşan compute maliyetiyle yan yana koyunca fark daha net görünüyor.

Docker container optimizasyonu da bu işin sessiz ama önemli tarafı. İmaj şişkinse geçiş sırasında can sıkabiliyor; şey, her şey yolunda giderken bile deploy süresi uzuyor. Eğer container imajlarınızı küçültmek istiyorsanız Docker İmajını Küçültmek: 1,58 GB’dan 186 MB’a yazımız işinize yarayabilir.

Sıkça Sorulan Sorular

Ingress2Gateway mevcut Ingress resource’larımı otomatik olarak siliyor mu?

Bence, Hayır, kesinlikle silmiyor (ciddiyim). Ingress2Gateway aslında sadece bir çeviri aracı — mevcut resource’larınıza hiç dokunmuyor. Çıktıyı size gösteriyor, apply etme kararı tamamen sizin elinde. Bence bu çok bilinçli bir tasarım kararı; production güvenliği açısından da tam olması gereken yaklaşım bu.

Gateway API’ye geçmek için Ingress-NGINX’in emekliye ayrılmasını beklemeli miyim?

Doğrusu, Beklemeyin. Hani Mart 2026 deadline’ı var ve son dakikaya bırakmak gereksiz risk. Açıkçası, staging ortamında şimdiden denemeye başlamak çok daha mantıklı. Paralel çalıştırma stratejisiyle hiç risk almadan geçiş yapabilirsiniz (ben de ilk duyduğumda şaşırmıştım). Erken başlamak neredeyse her zaman avantaj sağlıyor.

Hangi Gateway API controller’ını seçmeliyim?

Bu tamamen altyapınıza bağlı. Mesela Envoy Gateway genel amaçlı ve iyi dokümante edilmiş — çoğu senaryo için iyi bir başlangıç noktası. Cilium CNI kullanıyorsanız Cilium Gateway API mantıklı bir seçim oluyor. Azure AKS üzerindeyseniz Application Gateway for Containers’ı değerlendirin. Istio service mesh kullanıyorsanız zaten native Gateway API desteği geliyor, yani ekstra bir şeye gerek kalmıyor.

Ingress2Gateway tüm annotation’ları destekliyor mu?

Hayır, desteklemiyor. 1.0 sürümü 30’dan fazla yaygın annotation’ı kapsıyor ama Ingress-NGINX’in yüzlerce annotation’ı var. Desteklenmeyen annotation’lar için araç size bildirim gösteriyor ve alternatifler öneriyor. Tahmin eder misiniz? Tecrübeme göre çoğu kurumsal ortam için bu mevcut destek yeterli oluyor.

Geçiş sırasında downtime olur mu?

Paralel çalıştırma stratejisi kullanırsanız olmaz. Hem Ingress hem Gateway API aynı anda çalışıyor, traffic’i kademeli olarak yönlendiriyorsunuz. DNS veya load balancer seviyesinde geçiş yaparak sıfır kesinti hedefleyebilirsiniz — yani aslında bu tamamen sizin ne kadar dikkatli ilerlediğinizle ilgili (evet, doğru duydunuz)

Kaynaklar ve İleri Okuma

Ingress2Gateway 1.0 Resmi Duyuru Yazısı – Kubernetes Blog

Peki, size bir şey söyleyeyim, Kubernetes Gateway API Resmi Dokümantasyonu

Bir bakıma, bi saniye — Ingress2Gateway GitHub Deposu