KUBERNETES INGRESS NEDİR?

Cluster içindeki onlarca servisi tek bir alan adı üzerinden dışarı nasıl açarsınız? Her servise ayrı bir LoadBalancer atayıp bulut faturasını şişirmek mi, yoksa tüm trafiği tek bir kapıdan içeri alıp path ve host'a göre dağıtmak mı daha akıllıca? Kubernetes Ingress tam bu sorunun cevabı: cluster'a giren HTTP/HTTPS trafiğinin akıllı yönlendiricisi. Service ve LoadBalancer kavramlarıyla sık karıştırıldığı için ne zaman hangisini seçeceğinizi bilmek üretim ortamında ciddi maliyet ve operasyon farkı yaratır.

1. Ingress Nedir, Ne İşe Yarar?

Ingress, Kubernetes cluster'ına dışarıdan gelen HTTP ve HTTPS isteklerini cluster içindeki Service'lere yönlendiren bir API kaynağıdır. Tek başına bir şey yapmaz — bir Ingress Controller (NGINX, Traefik, HAProxy, AWS ALB, Istio Gateway gibi) tarafından okunup uygulanır. Ingress nesnesi yalnızca kuralları tanımlar: hangi host hangi servise gitsin, hangi path hangi backend'e düşsün, TLS sertifikası nereden gelsin.

Pratikte Ingress, cluster'ın önündeki ters proxy gibi davranır. api.veriakademi.com /v1 path'i bir mikroservise, /v2 path'i başka bir sürüme yönlendirilebilir; aynı IP üzerinden onlarca alan adı sunulabilir. Bu, her servis için ayrı bir bulut load balancer açmaya kıyasla hem ucuz hem yönetimi sade bir mimari getirir. Kavramın tüm alan tanımları ve davranış kuralları için resmi dokümantasyonu referans almak çoğu tartışmayı kestirip atar.

2. Service ve LoadBalancer ile Farkı

Karışıklığın kaynağı, üç kavramın da "trafik yönlendirme" başlığı altında yaşaması. Aralarındaki farkı katmanlar üzerinden ayırmak en sağlıklısı:

• ClusterIP Service: Cluster içi iletişim için sanal bir IP verir. Dışarıdan erişim yok; pod'lar birbirini bu IP üzerinden çağırır.
• NodePort Service: Her node üzerinde 30000-32767 aralığında bir port açar. Geliştirme ve hızlı testlerde işe yarar, üretim için kaba kalır.
• LoadBalancer Service: Bulut sağlayıcısından (AWS ELB, GCP LB, Azure LB) gerçek bir L4 load balancer ister. Her LoadBalancer servisi ayrı bir public IP ve ayrı bir fatura kalemi demektir.
• Ingress: L7 katmanında çalışır. Tek bir LoadBalancer'ın arkasında host/path tabanlı yönlendirme, TLS sonlandırma, rewrite, rate limit gibi HTTP'ye özgü işleri yapar.

Yani Ingress, LoadBalancer'ın yerine geçmez — onun üzerine kurulur. Tipik üretim kurulumunda cluster'da tek bir LoadBalancer Service vardır (Ingress Controller'ın kendisi), arkasında onlarca Ingress kuralı çalışır.

3. Ne Zaman Hangisini Seçmeli?

Pratik karar tablosu şu şekilde özetlenebilir:

1. Sadece cluster içi haberleşme: ClusterIP yeterli. Veritabanı, internal API, cache servisleri buraya girer.
2. Tek bir TCP/UDP servisini dışarı açmak (HTTP değil): LoadBalancer Service. Örneğin bir Redis cluster'ı, MQTT broker, oyun sunucusu.
3. Birden fazla HTTP/HTTPS servisini tek alan adı altında toplamak: Ingress. Web siteleri, REST API'ler, admin panelleri.
4. Yerel geliştirme veya geçici demo: NodePort hızlı çözüm. Üretime taşırken dönüştürün.
5. Gelişmiş trafik yönetimi (canary, mTLS, observability): Ingress yetmeyebilir; Gateway API veya service mesh (Istio, Linkerd) düşünün.

Ingress'in en büyük kazancı maliyet ve operasyonel sadeliktir. 20 mikroservisi 20 ayrı LoadBalancer ile açtığınızda bulut faturasının nasıl katlandığını ilk ay sonunda görürsünüz; aynı kurguyu tek Ingress Controller ile yaptığınızda hem IP, hem sertifika, hem log yönetimi tek noktaya iner.

4. Ingress Controller Seçimi

Ingress kaynağı standarttır, ancak onu yorumlayan Controller'lar farklı özellikler sunar. En yaygın seçenekler:

• ingress-nginx: Topluluk tarafından bakılan, en yaygın controller. Çoğu senaryoda iyi bir varsayılan.
• Traefik: Otomatik servis keşfi ve Let's Encrypt entegrasyonu güçlü; dashboard'u kullanışlı.
• HAProxy Ingress: Yüksek trafik ve düşük gecikme isteyen ortamlar için.
• Cloud Native: AWS Load Balancer Controller, GKE Ingress, AGIC — bulut sağlayıcısının native LB'sini doğrudan sürer.
• Istio Gateway / Gateway API: Mesh ile entegre, daha zengin yönlendirme. Ingress'in halefi olarak Gateway API standartlaşıyor.

Kubernetes ekosistemini uçtan uca öğrenmek isteyenler Kubernetes eğitimi içeriklerinden yararlanabilirsiniz; Ingress, Service ve Gateway API konuları orada pratik örneklerle işleniyor.

5. Basit Bir Ingress Manifest Örneği

Aşağıdaki manifest, iki farklı path'i iki farklı servise yönlendiren minimal bir Ingress'tir:

• apiVersion: networking.k8s.io/v1
• kind: Ingress
• metadata.name: app-ingress
• spec.rules[0].host: app.veriakademi.com
• http.paths[0].path: /api → backend: api-service:80
• http.paths[1].path: /web → backend: web-service:80

TLS eklemek için spec.tls bloğunda bir Secret referansı yeterlidir; cert-manager ile bu Secret otomatik üretilip yenilenebilir. Controller, manifest'i okur okumaz NGINX yapılandırmasını günceller ve trafiğiniz yeni kurallara göre akmaya başlar.

6. Sık Yapılan Hatalar

Üretim ortamlarında en çok karşılaşılan tuzaklar şunlar:

• Ingress nesnesini yazıp Controller kurmayı unutmak — kurallar hiçbir şey yapmaz.
• Her servise ayrı LoadBalancer Service tanımlayıp Ingress'i de eklemek; gereksiz IP ve maliyet birikir.
• TLS sertifikalarını manuel yönetmek; cert-manager kurmadan sertifika rotasyonu unutulur.
• ingressClassName belirtmeyip birden fazla Controller arasında çakışmaya yol açmak.
• Path tipini (Prefix / Exact / ImplementationSpecific) yanlış seçip beklenmeyen yönlendirmeler yaşamak.

Ingress'i sade haliyle "cluster'ın HTTP kapısı" olarak düşünmek karar verirken çoğu zaman yeterlidir: L4 ihtiyaçları için LoadBalancer, iç iletişim için ClusterIP, HTTP dünyasının tüm karmaşıklığı için Ingress. Bu üçlüyü doğru yerleştiren bir mimari, hem bulut faturasını hem operasyon yükünü kayda değer biçimde aşağı çeker. Daha derin trafik yönetimi gerektiğinde Gateway API ve service mesh seçeneklerini değerlendirmek için Kubernetes eğitimi kaynaklarını inceleyebilirsiniz.