Şaka değil, takvim işliyor
İtiraf edeyim, Kubernetes tarafında bazen öyle haberler düşer ki, ilk anda “sonra bakarım” dersiniz. Bu o tıp bir şey değil. Ingress NGINX’in emekliye ayrılması, hani kenara koyup unutacağınız bir konu hiç değil; çünkü konuştuğumuz şey kurumsal yapılarda giriş trafiğinin kapısı, yanı internetten içeri gelen isteklerin önemli bir kısmını taşıyan katman. Bir kapının kilidi değişiyorsa, anahtarın kimde olduğunu bugün kontrol edersiniz. Yarın değil.
Açık konuşayım, Açık konuşayım, bu tıp altyapılarda en tehlikeli durum sessiz çalışmasıdır. Sistem ayakta görünür, uygulamalar yanıt verir, dashboard yeşildir… ama altta kullanılan parça artık bakım almıyordur. Ben bunu 2023’te İstanbul’daki bir finans müşterisinde yaşadım; gateway tarafında küçük görünen bir bileşen güncellemesi ertelenmişti ve üç ay sonra güvenlik ekibi “bu sürümün desteği bitmiş” diye masaya oturdu. İşin can sıkıcı tarafı şu: sorun patlamadan fark edilmiyor.
Durun, bir saniye.
İşin aslı şu ki Ingress NGINX uzun süre çok sevildi çünkü esnekti. Fazla esneklik bazen iyi gelir, bazen de başınıza iş açar. Mimarının ilk dönemlerinde bu rahatlık avantajdı; ama zaman geçtikçe teknik borç birikti, bakım yükü arttı ve güvenlik tarafı daha hassas hâle geldi. Bunu 2019’da kendi lab ortamımda da görmüştüm: küçük bir değişiklik tüm yönlendirme zincirini etkileyebiliyor, dokümantasyon işe o anki gerçek durumu tam anlatmıyordu.
Neden bu kadar kritik?
Şimdi gelelim can alıcı yere: burada sadece “bir proje kapanıyor” demiyoruz. Bugün Ingress NGINX kullanan ekiplerin önemli bir kısmı farkında olmadan risk altında olabilir. Çünkü mevcut kurulumlar çalışmaya devam edecek; yanı ekranlarda alarm çalmayabilir. Fakat yeni güvenlik yaması gelmeyince mesele başka bir yere kayıyor: saldırgan için açık kapı kalabiliyor.
Benim AZ-104. AZ-305 hazırlıklarında da en çok vurguladığım şeylerden biri şuydu: mimariyi tasarlarken sadece bugünü değil, yaşam döngüsünü düşünmek gerekir. Bir bileşenin “şu an çalışıyor olması”, onun sağlıklı olduğu anlamına gelmez. Hele hele edge tarafında duran parçalarda bu daha sert hissedilir. Ha bu arada, kurumsal tarafta çoğu ekip teknoloji seçiminde performansa bakıyor; destek süresi işe sonradan akla geliyor. Tam tersi olmalıydı.
Ingress NGINX emekliliği bana göre teknik bir haberden çok operasyonel uyarı sinyali. Bugün kontrol etmezseniz, yarın bunu güvenlik ihlali olarak öğrenebilirsiniz.
Bir de şu var: alternatifler var ama hiçbiri birebir tak-çalıştır değil (yanlış duymadınız). Gateway API güzel gidiyor, evet; fakat geçişte politika mantığı, trafik yönetimi. Gözlemleme pratikleri yeniden ele alınmalı. Peki bunu neden söylüyorum? Kısacası mesela dükkân kapısını otomatik kayar kapıya çevirmek gıbı düşünün — giriş yine giriş ama montaj ayrı mesele.
Kısa bir not düşeyim buraya.
Kendi sahamda gördüğüm tablo
Geçen yıl Ankara’da bir üretim firmasına danışmanlık verirken benzer bir durumla karşılaştık. Ekip yıllardır aynı ingress yaklaşımını kullanıyordu ve sistem gayet sakın görünüyordu. Sonra container güvenlik taramasında eski bağımlılıklar ortaya çıktı; meğer kritik yolun üstünde kimsenin bakmadığı birkaç parça kalmıştı. O toplantıda herkes aynı cümleyi söyledi: “Bunu niye daha önce konuşmadık?” Çünkü işler sorunsuz giderken konu masaya zor düşüyor (evet, doğru duydunuz)
Bence, Bir başka örnek de 2024 yazında Dubai’de çalışan hibrit bir müşteriden geldi. Orada küçük ekip vardı ama trafik büyüktü; startup hızında başlayıp enterprise yükü taşımaya başlamışlardı. Böyle yerlerde Ingress NGINX gıbı çözümler ilk etapta iş görüyor, hatta bayağı iş görüyor diyebilirim, ama ölçek büyüdükçe yönetim modeli yetmemeye başlıyor. Güzel özellik ama biraz ham kalmışsa siz önü üretimde taşırken bedelini ödersiniz.
Bu servisi ilk denediğim yıllarda ben de hata yaşamıştım: yanlış annotation yüzünden path yönlendirmesi beklediğim gıbı çalışmamıştı ve test ortamında bile kafa karıştırmıştı. Çözüm basitti ama öğreticiydi; konfigürasyonu sadeleştirip trafiği katman katman doğruladık (önce service düzeyi, sonra ingress). İşte bazen sorun kodda değil, varsayımlardadır.
Ve işler burada ilginçleşiyor. Azure DevOps Server Haziran Patch’leri: Saha Notlarım yazımızda bu konuya da değinmiştik. Bu konuyla ilgili Foundry Observability Build 2026: Agent’tan ROI’ye Tam yazımıza da göz atmanızı tavsiye ederim.
Kimler hemen aksiyon almalı?
Burada herkese aynı reçete yoktur ya hani… Küçük bir startup iseniz öncelik hızlı keşif ölür; büyük kurumsalsanız değişiklik yönetimi. Bağımlılık haritası çıkarma işi öne çıkarırız:
| Senaryo | Ne yapmalı? | Neden? |
|---|---|---|
| Küçük ekip / startup | Hızlı envanter çıkarın, Gateway API veya hafif üçüncü parti controller deneyin | Teknik borcu erken kesmek kolay ölür |
| Orta ölçek | Trafik desenlerini analiz edip pilot cluster açın | Düşük riskle geçiş planlanır |
| Enterprise | Migrasyon dalgaları oluşturun, security ve platform ekiplerini aynı masaya oturtun | SLA ve uyumluluk gereksinimleri yüzünden kontrollü gitmek şarttır |
E tabi maliyet tarafını da konuşmak lazım. Azure üzerinde bunun doğrudan fiyat etiketi yok gıbı görünse de asıl maliyet insan saatidir: test ortamları, manifest revizyonları, regresyon testleri, eğitim derken toplam efor artar. TL bazında bakınca küçük görünen gecikme bile ciddi operasyon maliyetine döner çünkü birkaç kişinin iki hafta boyunca uğraşması demek boşuna para yakmak demektir. Daha fazla bilgi için Foundry Local 1.2: Edge AI Geliştirmeyi Hızlandırma Notlarım yazımıza bakabilirsiniz.
İlk adım olarak ne yapabilirsiniz?
Şöyle söyleyeyim, Lafı gevelemeden söyleyeyim: önce kullandığınız ingress controller’ı bulun sonra sahiplik atayın sonra da migrasyon tarihini yazın. Daha fazla bilgi için Visual Studio’da PR İnceleme: Tarayıcıya Veda Vakti yazımıza bakabilirsiniz.
kubectl get pods --all-namespaces --selector app.Kubernetes.io/name=ingress-nginx
kubectl get ingressclass
kubectl describe ingress -A
Şöyle söyleyeyim, Eğer bu komutların çıktısını yorumlamakta zorlanıyorsanız tek değilsiniz; geçen sene İzmir’deki bir lojistik projesinde aynısını yaşadık. Ilk turda beş farklı namespace bir düşüneyim… altında birbirinden köpük konfigürasyon bulduk. Birkaç saat içinde tablo netleşti ama o ilk şok… açıkçası güzeldi diyemem.
Bence doğru rota ne?
Bana sorarsanız iki seçenek öne çıkıyor: Gateway API’ye geçiş ya da ihtiyaca göre üçüncü parti controller kullanımı. Hangisi doğru? Kullanım senaryosuna bağlı tabii ki… Eğer trafik politikalarınız basitse Gateway API iyi bir temel veriyor. Bazı kurumlar hâlâ klasik annotation alışkanlığından vazgeçemiyor çünkü ekipler oraya kod yazmadan alışmış durumda.
Şunu söyleyeyim, Ben AZ-500 çalışmalarında hep şunu söylerim: güvenlik ürün seçimi kadar davranış değişikliğidir de mesele düzenleme yapmak kolaydır ama kültürü değiştirmek zordur inanın bana Ingress geçişi de biraz böyle yeni araç kurmak yarım gün sürer alışkanlığı değiştirmek haftalar alır özellikle büyük organizasyonlarda iş akışı onaysız ilerlemez bence en çok zaman orada gider.
Neyi sevmiyorum?
Şunu söyleyeyim, Dürüst olayım, benim biraz hayal kırıklığım şu öldü: böyle yaygın kullanılan bir bileşenin bakımının yıllarca birkaç kişinin omzunda kalması pek hoş değilmiş meğersem ekosistem büyürken sürdürülebilirlik planının erkenden yapılması gerekiyordu şimdi geriye dönüp bakınca bu açıkça görülüyor bugün karar sert ama gerekli görünüyor. Daha fazla bilgi için Azure Repos’a Copilot Code Review Geldi: Saha Notları yazımıza bakabilirsiniz.
Migrasyonda pratik yol haritası
Bunu yaşayan biri olarak söyleyeyim, Neyse uzatmayalım… Eğer gerçekten harekete geçecekseniz sırayı bozmayın:
- Tüm cluster’larda Ingress NGINX kullanımını tespit edin.
- Trafik yoğunluğu yüksek olan namespace’leri önceliklendirin.
- Pilot ortamda alternatif controller veya Gateway API deneyin.
- Metrikleri kıyaslayın; latency hatalarını ve retry davranışını izleyin.
- Migrasyonu dalga dalga canlıya alın ve rollback planını hazır tutun.
Kubernetes AI Gateway Working Group üzerine yazdığım notlarda da benzer şeyi vurgulamıştım: yönlendirme katmanı yalnızca HTTP trafiği taşımaz, ekiplerin çalışma şeklini de taşır sürekli elle müdahale edilen sistemlerde inovasyon yavaşlar otomasyon varsa rahat nefes alırsınız hani günlük hayatta ışıkları tek tek açmak yerine akıllı anahtara geçmek gıbı düşünün.
Büyük kurumlarda ayrıca compliance boyutu devreye giriyor ihaleler SLA maddeleri destek matrisi bunların hepsi söz konusu olunca karar sadece teknik ölmüyor mesela bankacılık tarafında migration planına denetim izi eklemek şart oluyor sigorta sektöründe işe bakım penceresi çok sınırlı kalabiliyor. Her sektörde ritim farklıdır bunu atlamayın derim.
Sıkça Sorulan Sorular
Ingress NGINX gerçekten kapanıyor mu?
Evet, maalesef öyle. Yeni sürümler çıkmayacak, aktif bakım da olmayacak. Yanı güvenlik yaması ya da bug fix beklemeyin artık. Açıkçası bu durum, mevcut kullanımı ciddi bir risk hâline getiriyor.
Benim sistemim etkileniyor mu, nasıl anlarım?
Aslında, En klasik yöntem pod etiketlerine bakmak. kubectl get pods --all-namespaces --selector app.Kubernetes.io/name=ingress-nginx komutu size güçlü bir ipucu veriyor. Bir de ingress class tanımlarınıza bakın, hani bazı kurulumlar dolaylı yoldan kullanıyor olabiliyor.
Gateway API tam anlamıyla yerine geçer mi?
Hayır, birebir drop-in replacement sayılmıyor. Geçişte manifest yapıları, trafik politikaları, operasyon süreçleri — bunların hepsi yeniden ele alınıyor. Ama bence uzun vadede çok daha temiz bir model sunuyor, yatırım yapmaya değer.
Küçük ekipler ne yapmalı?
Önce hızlıca envanter çıkarın. Sonra basit bir pilotla alternatifi deneyin. Eforu az tutmak istiyorsanız minimum değişiklikle başlayan bir tasarım seçin (şaşırtıcı ama gerçek). Tecrübeme göre en önemli şey şu: üretimde kör uçuş yapmayın lütfen.
Kaynaklar ve İleri Okuma
Kubernetes Resmî Duyurusu — Ingress NGINX Statement
Gateway API Resmî Dokümantasyonu (buna dikkat edin)
Azure Architecture Center — Giriş Trafiği Mimarı Örnekleri
Daha önce yazdıklarımdan ilgili notlar
Kubernetes tarafında benzer dönüşümlere bakarken Gateway API’yi kind ile Deneme: Lokal Lab Kurulumu yazısındaki lab yaklaşımı işe yarıyor; aslında prod’a atlamadan önce küçük çapta görmek her zaman iyi bir fikir.
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.
