Kubernetes Ingress Routing: Mermaid Diagram

Kubernetes Ingress Routing flowchart diagram

About Source

Kubernetes Ingress is an API object that manages external HTTP and HTTPS access to services within a cluster, providing host-based and path-based routing, TLS termination, and name-based virtual hosting — all configured through Kubernetes manifests.

Without Ingress, exposing multiple HTTP services externally requires one LoadBalancer Service per service, each provisioning a separate cloud load balancer and IP address — expensive and operationally burdensome. Ingress consolidates this into a single cloud load balancer fronting an Ingress controller (nginx, Traefik, HAProxy, or a cloud-native controller like AWS ALB Ingress Controller) running inside the cluster.

An Ingress resource defines routing rules:

- Host-based routing: api.example.com → api-service:80, app.example.com → frontend-service:80 - Path-based routing: example.com/api/* → api-service, example.com/static/* → static-service - TLS termination: The Ingress controller reads a Kubernetes TLS Secret (containing certificate and private key) and terminates HTTPS at the controller, forwarding plain HTTP to backend services internally.

The Ingress controller watches the Kubernetes API for Ingress resource changes and dynamically reconfigures its proxy (e.g., regenerating nginx.conf) without downtime. Traffic flows: client → cloud LB → Ingress controller pod → cluster Service → application pods.

Annotations on the Ingress object configure controller-specific behavior: rate limiting, authentication, CORS headers, WebSocket support, and custom error pages. For lower-level TCP/UDP routing within the cluster, see Kubernetes Service Routing. For request flow from the CDN to the load balancer, see CDN Edge Caching.

Frequently asked questions

Kubernetes Ingress is an API object that manages external HTTP and HTTPS access to services within a cluster. It provides host-based and path-based routing, TLS termination, and name-based virtual hosting — all configured through Kubernetes manifests and implemented by an Ingress controller running inside the cluster.

An Ingress controller (nginx, Traefik, or a cloud-native controller like AWS ALB Ingress Controller) watches the Kubernetes API for Ingress resource changes and dynamically reconfigures its proxy. Traffic flows from the client to a cloud load balancer, then to the Ingress controller pod, which matches the request host and path against rules and forwards it to the appropriate backend Service.

A LoadBalancer Service provisions a single cloud load balancer per service, incurring cost and IP address overhead at scale. An Ingress controller consolidates many services behind a single cloud load balancer, handling routing in-cluster based on HTTP rules. Ingress is therefore the standard approach for exposing multiple HTTP services, while LoadBalancer Services are used for non-HTTP TCP/UDP workloads.

Not configuring TLS leaves services exposed over plain HTTP. Using overly broad path rules (e.g., `/*`) that shadow more specific rules causes routing surprises. Forgetting to set resource requests on the Ingress controller pod means it can be evicted under pressure, causing a full traffic outage. Missing rate limiting annotations leaves the cluster exposed to request floods.

mermaid

flowchart TD
    Client([HTTPS Request\nexample.com]) --> CloudLB[Cloud Load Balancer\nexternal IP]
    CloudLB --> IngressCtrl[Ingress Controller\nnginx / Traefik / ALB]
    IngressCtrl --> TLS[TLS Termination\nread Secret: tls-cert]
    TLS --> HostMatch{Host Header\nMatch?}
    HostMatch -->|api.example.com| PathMatchAPI{Path Match}
    HostMatch -->|app.example.com| FrontendSvc[Service: frontend\nport 80]
    HostMatch -->|No match| Default404([Default Backend\n404 Not Found])
    PathMatchAPI -->|/api/users/*| UserSvc[Service: user-api\nport 8080]
    PathMatchAPI -->|/api/orders/*| OrderSvc[Service: order-api\nport 8080]
    PathMatchAPI -->|/api/static/*| StaticSvc[Service: static-files\nport 80]
    UserSvc --> UserPods[User API Pods]
    OrderSvc --> OrderPods[Order API Pods]
    FrontendSvc --> FrontendPods[Frontend Pods]
    StaticSvc --> StaticPods[Static File Pods]