Kubernetes-Ingress-Diagramm: Der Traffic-Fluss visualisiert

In fast jeder Architekturdoku gibt es eines: eine Box mit der Aufschrift „Ingress“ und einen Pfeil direkt auf eine Reihe von Pods. Das sieht gut aus, bis jemand beim Debuggen eines 502 fragt, wo TLS endet, welcher Proxy die Verbindung hält oder warum eine NetworkPolicy Traffic blockiert, der doch „durch den Ingress geht“. Ein gutes Kubernetes Ingress Diagramm beantwortet diese Fragen, bevor sie jemand stellt. Dieser Beitrag geht den Request-Pfad Hop für Hop durch, ordnet ein minimales Ingress-Manifest Boxen und Pfeilen zu, listet die häufigsten Fehler aus Reviews auf und zeigt, wie du dasselbe Diagramm in Archboard baust.

Der Request-Pfad, Hop für Hop

Verfolge https://shop.example.com/api/orders vom Client bis in den Container:

1. Client → DNS. Der Client löst shop.example.com auf. Der Eintrag (A/AAAA, CNAME oder ein Provider-Alias) zeigt auf den Cloud-Load-Balancer, nicht auf einen Node.
2. DNS → Cloud-Load-Balancer. Der Client verbindet sich mit dem Load Balancer. In den meisten Clustern existiert er, weil der Ingress-Controller über einen Service vom type: LoadBalancer exponiert ist; die Cloud-Integration legt ihn an und leitet an Node-Ports oder direkt an die Controller-Pods weiter.
3. Load Balancer → Ingress-Controller. Der Controller ist ein ganz normaler Workload (Deployment oder DaemonSet) mit einem Reverse Proxy wie NGINX, Envoy, HAProxy oder Traefik. Er ist die Komponente, die Verbindungen annimmt und Requests weiterleitet.
4. Ingress-Regeln (Host/Pfad). Der Controller beobachtet Ingress-Objekte seiner Klasse und übersetzt sie in Proxy-Konfiguration. Das Ingress-Objekt selbst fasst kein einziges Paket an. Es ist Konfiguration.
5. Service (ClusterIP). Jede Regel verweist auf einen Service-Namen und -Port. Der Service liefert einen stabilen Namen und wählt Pods per Label aus.
6. EndpointSlices. Die Control Plane hält die Pod-IPs hinter jedem Service, jeweils mit einer Ready-Bedingung, in EndpointSlice-Objekten fest. Viele Controller, auch ingress-nginx, lesen EndpointSlices und schicken Traffic direkt an Pod-IPs statt an die ClusterIP. Der Service muss trotzdem existieren: Über ihn findet der Controller diese Endpoints.
7. Pods. Der Request landet auf einem Container-Port in einem der bereiten Pods.

Ein Hinweis zu ingress-nginx: Der Community-Controller ingress-nginx wurde im März 2026 in den Ruhestand geschickt und bekommt keine Releases, Bugfixes oder Sicherheitspatches mehr. Er ist weiterhin das bekannteste Beispiel; für einen neuen Cluster wähle einen gepflegten Controller oder die Gateway API.

TLS-Terminierung: Grenze wählen und einzeichnen

Es gibt drei übliche Stellen, an denen HTTPS endet:

Das Secret muss im selben Namespace liegen wie der Ingress, der darauf verweist. Wenn du am Load Balancer terminierst und zum Controller neu verschlüsselst, zeichne zwei TLS-Segmente, nicht eines.

Host-Routing vs. Pfad-Routing

• Host-Routing schickt verschiedene Hostnamen an verschiedene Backends (shop.example.com vs. admin.example.com). Zeichne pro Host eine Gruppe von Kanten.
• Pfad-Routing teilt einen Host nach URL-Pfad auf. Mit pathType: Prefix wird über durch / getrennte Pfadelemente verglichen, also passt /api auf /api/orders, aber nicht auf /apiv2. Exact passt nur auf genau diesen Pfad; ImplementationSpecific hängt vom Controller ab.
• Passen mehrere Pfade, gewinnt der längste. Die meisten echten Ingresses kombinieren Host- und Pfadregeln.

Wo NetworkPolicy greift

NetworkPolicy filtert Pod-Traffic auf L3/L4, und das nur, wenn das Netzwerk-Plugin des Clusters sie durchsetzt. Sie kennt weder Hosts noch Pfade und hängt nicht am Ingress-Objekt. Im Diagramm betrifft sie den Hop Controller-Pods → Anwendungs-Pods. Hat der App-Namespace eine Default-Deny-Policy für eingehenden Traffic, ergänze eine Policy, die Traffic aus dem Controller-Namespace erlaubt, etwa mit einem namespaceSelector auf kubernetes.io/metadata.name: ingress-nginx. Den Hop Load Balancer → Controller regeln Cloud-Firewall-Regeln plus eventuelle Policies im Controller-Namespace.

Mehrere Ingress-Klassen

Cluster betreiben oft mehr als einen Controller: öffentlich und intern, oder alt und neu während einer Migration. Jeder Controller beansprucht eine IngressClass, und jeder Ingress wählt eine per spec.ingressClassName. Eine Klasse lässt sich mit der Annotation ingressclass.kubernetes.io/is-default-class: "true" als Standard markieren. Gib jedem Controller einen eigenen Pfad von seinem eigenen Load Balancer und beschrifte jeden Ingress mit seiner Klasse – sonst nehmen Leser an, dass ein einziger Proxy alles abwickelt.

Gateway API in Kürze

Die Gateway API (gateway.networking.k8s.io) ist die neuere, rollenorientierte Alternative: Eine GatewayClass beschreibt die Implementierung, ein Gateway definiert Listener und TLS (meist Sache des Plattform-Teams), und HTTPRoutes enthalten die Routing-Regeln (meist Sache der App-Teams). Das zentrale HTTP-Routing ist seit v1.0 im Jahr 2023 GA. Die Ingress API ist weiterhin GA und unterstützt, aber eingefroren: Sie bekommt keine neuen Features. Das Diagramm ändert sich kaum: Das Gateway tritt an die Stelle des Controller-Listeners, HTTPRoutes an die Stelle der Ingress-Regeln.

Ein minimaler Ingress im Kubernetes Ingress Diagramm

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 passt auf beide Pfade; /api ist länger, also geht der Request an orders-api.

Häufige Fehler

• Den Ingress als Proxy zeichnen. LB → Ingress → Pods liest sich, als wäre der Ingress ein Pod. Der Controller ist der Proxy; der Ingress ist Konfiguration, die er liest. Setz den Controller in den Datenpfad und häng den Ingress mit einer gestrichelten Kante daran.
• Den Service weglassen. Ingress-Backends verweisen auf Services, nicht auf Pods. Selbst wenn Traffic direkt an Pod-IPs geht, ist der Service-Selector das, was bricht, wenn Labels auseinanderlaufen. Lass ihn im Diagramm.
• Keine TLS-Grenze. Zeigt das Diagramm nicht, wo HTTPS endet, kann niemand sagen, ob Traffic innerhalb der VPC im Klartext läuft.
• Eine schwebende NetworkPolicy. Eine Policy ohne Kante zu dem Hop, den sie regelt, erklärt nichts.

So baust du es in Archboard

Das Kubernetes-Pack von Archboard enthält vollwertige Nodes mit Ports für die oben genannten Objekte, darunter IngressClass, Gateway und Route, und das Network-Pack deckt DNS und den Load Balancer ab. Die fertige Version ist das Diagramm unten, und In Archboard öffnen kopiert es in deinen Workspace; /examples/kubernetes-ingress-flow ist eine kleinere Skizze von Ingress → Service → Pods. So baust du es selbst:

1. Leg ein Diagramm an und platziere einen Client (eine Core Box oder ein Icon oder eine C4 Person), dann einen DNS-Node und einen Load-Balancer-Node aus dem Network-Pack.
2. Füge einen Namespace-Frame ingress-nginx mit einem Deployment und einem Pod für den Controller hinzu. Die Kante vom Load Balancer geht an diesen Pod, denn er ist der Proxy.
3. Füge einen zweiten Namespace-Frame shop hinzu. Platziere darin den Ingress, ein Secret (shop-example-com-tls) und zwei Service-Nodes, orders-api und storefront, jeweils verbunden mit einem Deployment und einem Pod.
4. Verbinde die Ports entlang des Datenpfads: Client → DNS → Load Balancer → Controller-Pod → jeder Service (Kanten mit /api und / beschriften) → Pods. Beschrifte die Kanten Service → Pod mit „EndpointSlices“, damit Leser sehen, wie der Traffic die Pods erreicht.
5. Verbinde den Controller über eine gestrichelte „beobachtet“-Kante mit dem Ingress und das Secret mit dem Ingress.
6. Setz einen NetworkPolicy-Node in den shop-Frame und verbinde ihn mit dem Hop Controller → Anwendung, den er erlaubt.
7. Markiere die TLS-Grenze mit einem Core Frame oder einer Box um das verschlüsselte Segment und beschrifte, wo sie endet.
8. Füge das Ingress-YAML in einen Markdown-Block auf dem Canvas ein, direkt neben die Boxen, die es beschreibt.

Der Free-Plan erlaubt 15 Diagramm-Nodes pro Diagramm plus 150 Notizen und Texte. Der vollständige Aufbau oben nutzt 18, also lass die drei Deployment-Nodes weg, den des Controllers eingeschlossen, und verbinde Services direkt mit Pods; der Traffic-Pfad bleibt intakt. Exportiere als SVG oder PNG (im Free-Plan mit Wasserzeichen) oder als strukturiertes JSON, das du neben deinen Manifests ablegst. Für die Gesamtsicht auf den Cluster siehe /examples/kubernetes-microservices und Archboard für Kubernetes. Die Upstream-Referenz ist die Kubernetes-Dokumentation zu Ingress.

FAQ

Gehört der Ingress in den Namespace der Anwendung? Ja. Ingress ist ein Namespace-Objekt und kann nur Services und TLS-Secrets im eigenen Namespace referenzieren. Der Controller läuft meist in einem eigenen Namespace.

Läuft der Traffic über die ClusterIP des Service? Das hängt vom Controller ab. Viele leiten anhand der EndpointSlices direkt an Pod-IPs weiter. Zeichne den Service trotzdem und beschrifte die Kante.

Ingress oder Gateway API für einen neuen Cluster? Wenn dein Controller sie unterstützt: Gateway API, denn die Ingress API ist eingefroren. Die Methode fürs Diagramm bleibt gleich.

Kostenlos starten — ein Seat, keine Kreditkarte