Yazılarımız

Veri Akademi

KUBERNETES INGRESS NEDİR? TRAFİK YÖNETİMİ, TLS VE ROUTİNG MANTIĞI

Kubernetes üzerinde uygulamalar büyüdükçe “dış dünyadan gelen istekler hangi servise, hangi kurala göre gidecek?” sorusu kritik hale gelir. Servis türleri (ClusterIP, NodePort, LoadBalancer) temel ağ ihtiyaçlarını karşılar; ancak birden fazla domain, path’e göre yönlendirme, TLS sonlandırma, yeniden yazma (rewrite) gibi HTTP seviyesindeki ihtiyaçlar hızla karmaşıklaşır.

İşte bu noktada Kubernetes Ingress devreye girer. Ingress, küme dışından gelen HTTP/HTTPS trafiği için “kurallar seti” tanımlar; bu kuralları hayata geçiren bileşen ise Ingress Controller’dır. Ingress kaynaklarını doğru tasarladığınızda hem trafiği tek yerden yönetir hem de güvenliği, sertifika yenilemesini ve uygulama yayın stratejilerini daha tutarlı bir şekilde uygularsınız.

Bu yazıda Ingress’in ne olduğunu, Ingress Controller mantığını, routing (host/path) kurallarını, TLS yönetimini ve üretimde sık kullanılan pratik konfigürasyonları adım adım ele alacağız. Ayrıca gerçekçi YAML örnekleriyle temel bir kurulumdan, TLS + birden fazla servis yönlendirmesine kadar ilerleyeceğiz.


Kubernetes Ingress Temelleri: Kaynak, Rol ve Akış

Ingress, Kubernetes API’sinde bir tür kaynak (resource) olarak tanımlanır. Amacı, küme dışından gelen HTTP/HTTPS trafiği için kurallar tanımlamaktır. “Şu host gelirse şu servise git”, “şu path gelirse diğer servise git” gibi yönlendirme mantığını ifade eder. Ingress tek başına trafik taşımaz; kuralları uygulayan bir Ingress Controller gerekir.

Akış genellikle şu şekilde işler: İstemci (browser/SDK) bir domain’e istek atar → DNS bir IP’ye çözümleme yapar → bu IP çoğunlukla Load Balancer ya da reverse proxy’nin IP’sidir → Ingress Controller gelen isteği okur, Ingress kurallarıyla eşleştirir ve ilgili Kubernetes Service’e iletir → Service arkasındaki Pod’lara trafik dağıtır.

Ingress ile Service Arasındaki Fark

Service, Pod’ları sabit bir uç noktada toplar ve temel L4/L3 yönlendirme sağlar. Ingress ise HTTP/HTTPS gibi L7 (uygulama katmanı) detaylarıyla ilgilenir. Path-based routing, host-based routing, header temelli kurallar veya TLS gibi ihtiyaçlarda Service tek başına yeterli olmaz; Ingress bu katmanda kontrol sağlar.

Ingress Controller Nedir, Neden Şart?

Ingress Controller, Kubernetes API’sindeki Ingress kaynaklarını izleyen ve bu kuralları gerçek bir proxy/load balancer konfigürasyonuna dönüştüren bileşendir. Örneğin NGINX Ingress Controller, Ingress YAML’larını NGINX yapılandırmasına çevirir ve gelen istekleri kurallara göre iletir. Controller olmadan Ingress kaynakları “kağıt üzerinde” kalır.

Ingress Routing Mantığı: Host ve Path Kuralları

Ingress’in en çok kullanılan gücü, routing kurallarını tek bir kapıdan yönetmesidir. Aynı IP/Load Balancer üzerinde birden fazla domain’i barındırabilir, path’e göre farklı servisleri hedefleyebilir. Bu sayede “/api” istekleri backend’e, “/” istekleri frontend’e gidebilir.

Birden fazla uygulamanın aynı alan adı altında / ve /api yollarıyla farklı servislere ayrıldığı yönlendirme mantığı

Host Bazlı Yönlendirme

Host bazlı routing, farklı domain’leri farklı servislere yönlendirmek için kullanılır. Örneğin app.example.com ile admin.example.com aynı cluster’da çalışabilir; Ingress kuralları host alanına göre hedef servisi belirler. Bu yaklaşım çoklu uygulama barındırma ve ortamlara göre ayrım (staging/prod) için pratiktir.

Path Bazlı Routing ve Öncelik Sırası

Path bazlı routing, aynı host üzerinde farklı URL yollarını farklı servislere dağıtır. Genel olarak daha spesifik path kuralları öncelikli değerlendirilir. Örneğin “/api” kuralı, “/” kuralından daha spesifik olduğu için öncelikli eşleşmelidir. Controller'ın pathType davranışını (Prefix/Exact/ImplementationSpecific) anlamak üretimde sürprizleri azaltır.

Ingress YAML ile İlk Kurulum: Gerçekçi Bir Örnek

Aşağıdaki örnek, iki servisi (frontend ve api) path bazlı olarak yönlendiren temel bir Ingress tanımıdır. Burada “ingressClassName” ile hangi controller'ın bu Ingress’i işleyeceğini belirtmek iyi bir pratiktir. Ayrıca kurallar netleştikçe ortamlar arasında taşımak kolaylaşır.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
  namespace: default
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  ingressClassName: nginx
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-svc
            port:
              number: 80
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-svc
            port:
              number: 80

Bu yapı, “app.example.com/api” altındaki istekleri api-svc servisine, geri kalan tüm istekleri web-svc servisine yönlendirir. Gerçekte servislerin arkasında Deployment/Pod’lar bulunur ve Service bu Pod’lara yük dağıtır.

IngressClass ve Çoklu Controller Senaryosu

Aynı cluster’da birden fazla Ingress Controller çalıştırmak mümkündür (örneğin bir ekip NGINX, diğer ekip farklı bir controller kullanabilir). Böyle durumlarda IngressClass seçimi kritik hale gelir. “ingressClassName” ile doğru controller'a hedefleme yaparak, kuralların yanlış proxy tarafından uygulanmasını engellersiniz.

TLS ve HTTPS: Sertifika Yönetimi ve Termination

Ingress’in en önemli kullanım alanlarından biri TLS sonlandırmadır. İstemci ile Ingress Controller arasındaki bağlantı HTTPS olur; controller sertifikayı kullanarak trafiği çözer ve cluster içindeki servislere HTTP olarak iletebilir (veya isterseniz iç trafiği de TLS ile sürdürebilirsiniz). Bu yaklaşım, uygulama seviyesinde sertifika yönetimi yükünü azaltır.

TLS sertifikasının Ingress üzerinde yönetildiği ve HTTPS trafiğinin kontrol noktası üzerinden servis katmanına aktarıldığı akış

TLS Secret ve Ingress’e Bağlama

TLS için genellikle bir Kubernetes Secret kullanılır. Secret içinde “tls.crt” ve “tls.key” bulunur. Ingress spec altında “tls” bölümü ile host ve secretName tanımlanır. Böylece controller gelen HTTPS isteklerini ilgili sertifika ile karşılar.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress-tls
  namespace: default
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - app.example.com
    secretName: app-example-com-tls
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-svc
            port:
              number: 80

cert-manager ile Otomatik Sertifika Yenileme

Üretimde manuel sertifika yenilemek risklidir. Bu yüzden cert-manager gibi çözümlerle Let’s Encrypt üzerinden otomatik sertifika üretimi ve yenilemesi yaygındır. Tipik bir kurulumda ClusterIssuer/Issuer tanımlanır; ardından Ingress üzerinde ilgili annotation veya Certificate kaynağı ile sertifika yaşam döngüsü yönetilir. Böylece sertifika süresi dolduğunda otomatik yenileme gerçekleşir ve kesinti ihtimali düşer.

Ingress Annotations: İnce Ayar, Rewrite, Rate Limiting ve Daha Fazlası

Ingress, standart alanlar dışında birçok ince ayarı annotations üzerinden sağlar (controller’a göre değişir). Bu kısım güçlüdür ama yönetilmezse “gizli konfigürasyon” haline gelebilir. Bu nedenle kritik annotation’ları dokümante etmek ve ekip içinde standartlaştırmak iyi bir yaklaşımdır.

Rewrite Kuralları ve Uygulama Uyumluluğu

Uygulama “/” beklerken siz “/api” altından yayınlamak isteyebilirsiniz. Bu durumda controller, gelen path’i yeniden yazar. Örneğin NGINX Ingress tarafında rewrite-target gibi annotation’larla istek “/api/users” iken backend’e “/users” şeklinde iletilebilir. Bu, legacy uygulamaları Kubernetes’e taşırken sık kullanılan bir çözümdür.

Rate Limiting ve Koruma Katmanı

Ingress, temel bir koruma katmanı sağlayabilir. Rate limiting, istek başına limitler veya belirli endpoint’lere daha sıkı kurallar gibi ihtiyaçlar, controller özelliklerine bağlı olarak konfigüre edilebilir. Bu yaklaşım tek başına tam bir WAF yerine geçmez; ancak API’yi kaba trafik patlamalarına karşı daha dayanıklı hale getirir.

  • SSL redirect ile HTTP’den HTTPS’e zorunlu geçiş
  • Request size limitleri ile beklenmeyen payload riskini azaltma
  • Timeout ayarlarıyla uzun süren istekleri daha kontrollü yönetme
  • Header ekleme/çıkarma ile proxy standardizasyonu

Üretim Tasarımı: Blue/Green, Canary ve Çoklu Ortam Yönetimi

Ingress, yayın stratejilerinde de kritik rol oynar. Aynı servis için iki farklı sürümü (v1/v2) çalıştırıp, trafiği kademeli olarak yeni sürüme aktarabilirsiniz. Controller’a göre değişmekle birlikte ağırlık bazlı routing, belirli header/cookie ile yönlendirme gibi yöntemler mümkün olabilir. Böylece geri dönüş (rollback) daha hızlı ve güvenli olur.

Canary yayın stratejisinde trafiğin küçük bir yüzdesinin yeni sürüme yönlendirildiği ve metriklerle izlendiği senaryo

Çoklu Namespace ve Ortam Ayrımı

Staging ve production ayrımı yaparken namespace kullanımı yaygındır. Ancak aynı domain’i iki ortamda yönetmek isterseniz DNS ve Ingress IP/Load Balancer planı önem kazanır. Bazı ekipler her ortam için ayrı controller ve ayrı IP kullanır; bazıları aynı controller üzerinde farklı host’larla ayrıştırır. Burada hedef; tutarlılık ve hata ihtimalini azaltmaktır.

Gözlemlenebilirlik: Loglar, Metrikler ve Hata Ayıklama

Ingress kaynaklı problemlerde hızlı teşhis için controller logları, istek metrikleri (latency, 4xx/5xx oranı), upstream health ve TLS handshake istatistikleri izlenmelidir. Yanlış pathType, eksik host, hatalı TLS secret veya servis port uyumsuzluğu en sık karşılaşılan nedenler arasındadır. Ayrıca NetworkPolicy ve güvenlik grupları da trafik akışını etkileyebilir.

Pratik İpuçları ve Sık Yapılan Hatalar

Ingress ile ilgili en yaygın sorunlar genellikle “kural eşleşmiyor” ya da “TLS çalışmıyor” şeklinde görülür. Bu tür durumlarda önce DNS’in doğru IP’ye gidip gitmediğini, ardından controller'ın Ingress’i okuyup okumadığını, en son da backend servis/port eşleşmesini kontrol etmek sağlıklı bir sıralamadır.

Kontrol Listesi: Kurulum Sonrası Doğrulama

  1. DNS kaydı doğru IP’ye yönleniyor mu?
  2. Ingress Controller sağlıklı mı, ilgili namespace’te çalışıyor mu?
  3. IngressClass doğru seçilmiş mi?
  4. Service adı ve port numarası Ingress ile uyumlu mu?
  5. TLS secret doğru namespace’te mi ve içerik doğru mu?
  6. Path kuralları beklenen öncelikle mi eşleşiyor?

Ingress’i Derinleştirmek İçin Öğrenme Yolu

Ingress’i doğru kullanmak, Kubernetes ağ katmanını daha yönetilebilir ve güvenli hale getirir. Ancak üretimde “tek YAML” ile bitmez; controller seçimi, sertifika otomasyonu, güvenlik politikaları ve yayın stratejileriyle birlikte düşünmek gerekir. Bu konuları sistematik bir şekilde ele almak isterseniz, kapsamlı pratiklerle ilerlemek en hızlı yoldur.

Daha fazla örnek, senaryo ve uygulamalı yaklaşım için Kubernetes eğitimi sayfasına göz atabilirsiniz. Özellikle ingress controller kurulumu, TLS otomasyonu ve gerçek ortam troubleshooting bölümleri, günlük operasyonları daha rahat yönetmenize yardımcı olur.

Özetle: Kubernetes Ingress bir “trafik sözleşmesi” tanımlar; bu sözleşmeyi hayata geçiren Ingress Controller ise cluster'ın HTTP/HTTPS kapısıdır. Kuralları sade, gözlemlenebilir ve ekip standartlarına uygun tuttuğunuzda, routing ve güvenlik ihtiyaçlarını daha az sürprizle yönetirsiniz.

 VERİ AKADEMİ