Kubernetes Ingress Diyagramı: Trafik Akışı Adım Adım

Çoğu mimari dokümanda bir tane vardır: "Ingress" yazan bir kutu ve oradan doğrudan bir sıra Pod'a giden bir ok. 502 hatasını ayıklayan biri TLS'in nerede bittiğini, bağlantıyı hangi proxy'nin tuttuğunu ya da "Ingress'ten geçen" trafiği bir NetworkPolicy'nin neden engellediğini sorana kadar her şey yolunda görünür. İyi bir Kubernetes Ingress diyagramı bu soruları kimse sormadan yanıtlar. Bu yazıda isteğin yolunu adım adım izliyor, minimal bir Ingress manifestini kutulara ve oklara eşliyor, incelemelerde en sık görülen hataları sıralıyor ve aynı diyagramı Archboard'da nasıl kuracağınızı gösteriyoruz.

İsteğin yolu, adım adım

https://shop.example.com/api/orders isteğini istemciden container'a kadar izleyin:

1. İstemci → DNS. İstemci shop.example.com adını çözümler. Kayıt (A/AAAA, CNAME ya da sağlayıcı alias'ı) bir node'u değil, bulut yük dengeleyicisini gösterir.
2. DNS → bulut yük dengeleyici. İstemci yük dengeleyiciye bağlanır. Çoğu cluster'da bu yük dengeleyici, Ingress controller type: LoadBalancer tipinde bir Service ile dışarı açıldığı için vardır; bulut entegrasyonu onu oluşturur ve trafiği node port'larına ya da doğrudan controller Pod'larına iletir.
3. Yük dengeleyici → Ingress controller. Controller sıradan bir iş yüküdür (Deployment ya da DaemonSet) ve NGINX, Envoy, HAProxy veya Traefik gibi bir reverse proxy çalıştırır. Bağlantıları kabul eden ve istekleri proxy'leyen bileşen budur.
4. Ingress kuralları (host/path). Controller kendi sınıfındaki Ingress nesnelerini izler ve bunları proxy yapılandırmasına dönüştürür. Ingress nesnesinin kendisi hiçbir pakete dokunmaz; o bir yapılandırmadır.
5. Service (ClusterIP). Her kural bir Service adına ve port'una işaret eder. Service sabit bir ad sağlar ve Pod'ları label ile seçer.
6. EndpointSlices. Control plane, her Service'in arkasındaki Pod IP'lerini, her biri için bir ready koşuluyla birlikte EndpointSlice nesnelerinde tutar. ingress-nginx dahil pek çok controller EndpointSlices'ı okur ve trafiği ClusterIP yerine doğrudan Pod IP'lerine gönderir. Yine de Service var olmak zorundadır: controller bu endpoint'leri onun üzerinden bulur.
7. Pod'lar. İstek, hazır Pod'lardan birinin container port'una ulaşır.

ingress-nginx hakkında bir not: Topluluk ingress-nginx controller'ı Mart 2026'da emekliye ayrıldı ve artık sürüm, hata düzeltmesi ya da güvenlik yaması almıyor. Hâlâ en tanıdık örnek olduğu için burada kullanıyoruz; yeni bir cluster için bakımı süren bir controller ya da Gateway API seçin.

TLS sonlandırma: bir sınır seçin ve çizin

HTTPS'in bittiği üç yaygın yer vardır:

Secret, ona referans veren Ingress ile aynı namespace'te olmalıdır. Yük dengeleyicide sonlandırıp controller'a yeniden şifreliyorsanız tek değil, iki TLS segmenti çizin.

Host'a göre ve path'e göre yönlendirme

• Host'a göre yönlendirme farklı host adlarını farklı backend'lere gönderir (shop.example.com ve admin.example.com). Her host için bir kenar grubu çizin.
• Path'e göre yönlendirme tek bir host'u URL path'ine göre böler. pathType: Prefix ile eşleşme / ile ayrılan path öğeleri üzerinden yapılır; yani /api, /api/orders ile eşleşir ama /apiv2 ile eşleşmez. Exact yalnızca o path ile eşleşir; ImplementationSpecific ise controller'a bağlıdır.
• Birden fazla path eşleşirse en uzun olan kazanır. Gerçek Ingress'lerin çoğu host ve path kurallarını birlikte kullanır.

NetworkPolicy nerede devreye girer

NetworkPolicy, Pod trafiğini L3/L4'te filtreler ve bunu yalnızca cluster'ın ağ eklentisi uyguluyorsa yapar. Host'lardan ve path'lerden haberi yoktur, Ingress nesnesine de bağlanmaz. Diyagramda yönettiği adım, controller Pod'ları → uygulama Pod'ları adımıdır. Uygulama namespace'inde default-deny bir ingress policy varsa, controller'ın namespace'inden gelen trafiğe izin veren bir policy ekleyin; örneğin kubernetes.io/metadata.name: ingress-nginx üzerinde bir namespaceSelector ile. Yük dengeleyici → controller adımını ise bulut güvenlik duvarı kuralları ve controller namespace'indeki policy'ler yönetir.

Birden fazla Ingress sınıfı

Cluster'lar çoğu zaman birden fazla controller çalıştırır: biri herkese açık, biri dahili ya da bir geçiş sırasında eskisi ve yenisi. Her controller bir IngressClass sahiplenir, her Ingress de spec.ingressClassName ile birini seçer. Bir sınıf ingressclass.kubernetes.io/is-default-class: "true" annotation'ı ile varsayılan yapılabilir. Her controller'a kendi yük dengeleyicisinden gelen ayrı bir yol çizin ve her Ingress'i sınıfıyla etiketleyin; aksi hâlde okuyanlar her şeyi tek bir proxy'nin taşıdığını varsayar.

Kısaca Gateway API

Gateway API (gateway.networking.k8s.io), daha yeni ve rol odaklı alternatiftir: GatewayClass implementasyonu tanımlar, Gateway listener'ları ve TLS'i belirler (genelde platform ekibinin sorumluluğundadır), HTTPRoute'lar ise yönlendirme kurallarını taşır (genelde uygulama ekiplerinin sorumluluğundadır). Temel HTTP yönlendirmesi 2023'teki v1.0 sürümünden beri GA'dır. Ingress API hâlâ GA ve destekleniyor, ancak dondurulmuş durumda: yeni özellik almıyor. Diyagram neredeyse hiç değişmez: Gateway controller'ın listener'ının, HTTPRoute'lar da Ingress kurallarının yerini alır.

Minimal bir Ingress ve Kubernetes Ingress diyagramındaki karşılıkları

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop
  namespace: shop
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - shop.example.com
      secretName: shop-example-com-tls
  rules:
    - host: shop.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: orders-api
                port:
                  number: 8080
          - path: /
            pathType: Prefix
            backend:
              service:
                name: storefront
                port:
                  number: 80

/api/orders iki path ile de eşleşir; /api daha uzun olduğu için istek orders-api'ye gider.

Sık yapılan hatalar

• Ingress'i proxy gibi çizmek. LB → Ingress → Pod'lar dizisi, Ingress bir Pod'muş gibi okunur. Proxy controller'dır; Ingress onun okuduğu yapılandırmadır. Controller'ı veri yoluna koyun, Ingress'i ona kesikli bir kenarla bağlayın.
• Service'i atlamak. Ingress backend'leri Pod'lara değil, Service'lere referans verir. Trafik doğrudan Pod IP'lerine gitse bile label'lar kaydığında bozulan şey Service selector'üdür; bu yüzden diyagramda kalsın.
• TLS sınırı olmaması. Diyagram HTTPS'in nerede bittiğini göstermiyorsa, VPC içindeki trafiğin düz metin olup olmadığını kimse söyleyemez.
• Havada asılı NetworkPolicy. Yönettiği adıma hiçbir kenarla bağlanmayan bir policy hiçbir şey açıklamaz.

Archboard'da oluşturmak

Archboard'un Kubernetes paketinde IngressClass, Gateway ve Route dahil yukarıdaki nesneler için portlu birinci sınıf node'lar var; Network paketi de DNS ve yük dengeleyiciyi kapsıyor. Bitmiş sürüm aşağıdaki diyagramdır ve Archboard'da aç onu çalışma alanınıza kopyalar; /examples/kubernetes-ingress-flow ise daha küçük bir Ingress → Service → Pods taslağıdır. Kendiniz oluşturmak için:

1. Bir diyagram oluşturun ve bir istemci yerleştirin (Core Box ya da Icon veya bir C4 Person), ardından Network paketinden bir DNS node'u ve bir yük dengeleyici node'u ekleyin.
2. Controller için içinde bir Deployment ve bir Pod bulunan, ingress-nginx adlı bir Namespace çerçevesi ekleyin. Yük dengeleyiciden gelen kenar bu Pod'a gider, çünkü proxy odur.
3. shop adlı ikinci bir Namespace çerçevesi ekleyin. İçine Ingress'i, bir Secret (shop-example-com-tls) ve her biri bir Deployment ile bir Pod'a bağlı iki Service node'unu (orders-api ve storefront) yerleştirin.
4. Veri yolu boyunca port'ları bağlayın: istemci → DNS → yük dengeleyici → controller Pod'u → her Service (kenarları /api ve / olarak etiketleyin) → Pod'lar. Service → Pod kenarlarını "EndpointSlices" olarak etiketleyin; böylece okuyucu trafiğin Pod'lara nasıl ulaştığını görür.
5. Controller'ı Ingress'e kesikli bir "izler" kenarıyla, Secret'ı da Ingress'e bağlayın.
6. shop çerçevesine bir NetworkPolicy node'u ekleyin ve onu izin verdiği controller → uygulama adımına bağlayın.
7. TLS sınırını şifreli segmentin çevresine bir Core Frame ya da Box ile çizin ve nerede sonlandığını etiketleyin.
8. Ingress YAML'ını, anlattığı kutuların yanına, canvas üzerindeki bir Markdown bloğuna yapıştırın.

Free plan diyagram başına 15 diyagram node'una, ayrıca 150 not ve metne izin verir. Yukarıdaki tam kurulum 18 node kullanır, bu yüzden controller'ınki dahil üç Deployment node'unu çıkarın ve Service'leri doğrudan Pod'lara bağlayın; trafik yolu bozulmaz. SVG ya da PNG (Free'de filigranlı) olarak veya manifestlerinizin yanında saklamak için yapılandırılmış JSON olarak dışa aktarın. Cluster'ın genel görünümü için /examples/kubernetes-microservices ve Kubernetes için Archboard sayfalarına bakın. Upstream referans: Kubernetes Ingress dokümantasyonu.

SSS

Ingress uygulama namespace'inin içinde mi çizilmeli? Evet. Ingress namespace'e bağlı bir nesnedir ve yalnızca kendi namespace'indeki Service'lere ve TLS Secret'larına referans verebilir. Controller genellikle kendi namespace'inde çalışır.

Trafik Service'in ClusterIP'sinden geçer mi? Controller'a bağlıdır. Pek çoğu EndpointSlices üzerinden doğrudan Pod IP'lerine proxy'ler. Service'i yine de çizin ve kenarı etiketleyin.

Yeni bir cluster için Ingress mi, Gateway API mi? Controller'ınız destekliyorsa Gateway API; Ingress API dondurulmuş durumda. Diyagram yöntemi aynıdır.

Ücretsiz başlayın — tek kullanıcı, kredi kartı gerekmez