⌂ Home

Ingress Controllers

How HTTP and HTTPS requests reach the right Service inside your cluster: host and path rules, an Ingress controller at the edge, and stable Service-backed routing.

An Ingress resource declares Layer 7 routing (host, path, TLS). An Ingress controller must run in the cluster to enforce those rules and forward traffic to Services.

See also: EndpointSlices — how Kubernetes tracks backend Pod addresses for Services at scale.

Core Model

Understand the Concept First

Ingress adds Layer 7 routing

Host-based and path-based routing turn one entry point into many application routes.

Ingress Controller required

An Ingress resource needs a controller like NGINX or Traefik to become active.

TLS termination at the edge

Centralize HTTPS handling instead of per-app certificates when your controller supports it.

Visual Architecture

Interactive Flow Diagrams

External Client HTTP/HTTPS Ingress Controller (NGINX/Traefik) Match rules Ingress Rules host: app.example.com path: /api/* Route to Service (ClusterIP) app-service:80 Load balance Pod 1 10.244.1.5 Pod 2 10.244.1.6 Pod 3 10.244.1.7 Traffic Flow Explanation 1. External client sends HTTP/HTTPS request to domain 2. Ingress Controller receives and evaluates Ingress rules (host/path matching) 3. Matched rule routes traffic to corresponding Service, which load balances to backend Pods Complete Ingress + EndpointSlice Architecture Load Balancer (Cloud Provider) Ingress Controller Evaluates Ingress rules (host/path matching) Ingress Resource host: app.example.com → svc-a host: api.example.com → svc-b Service A selector: app=frontend EndpointSlice 10.244.1.5:8080 (Pod A1) 10.244.1.6:8080 (Pod A2) Service B selector: app=backend EndpointSlice 10.244.2.8:8080 (Pod B1) 10.244.2.9:8080 (Pod B2) Pod A1 frontend Pod A2 frontend Pod B1 backend Pod B2 backend Key Points • L7 routing via host/path rules • EndpointSlices track backends
Hover over diagram elements for detailed tooltips. Use the buttons above to switch between the routing view and the full edge-to-Pod architecture.
Lifecycle Flow

Traffic Path from Client to Pod

1

Client sends request

Traffic arrives with a host, path, and optionally TLS.

2

Ingress Controller receives traffic

The controller handles the network edge and interprets the request.

3

Ingress rules match

Host and path rules choose the target Service.

4

Service resolves backend set

The Service points to a set of eligible backend endpoints.

Ingress decides which Service should receive the request; the Service (and kube-proxy or your dataplane) forwards to healthy Pods behind it.
YAML and Commands

Examples You Can Recognize Quickly

Basic Ingress Pattern
kind: Ingress
spec:
  rules:
  - host: app.example.local
Useful Inspection Commands
kubectl get ingress
kubectl describe ingress <name>
Decision Guide

Service vs Ingress

Feature Service Ingress
Routing layer Layer 4 Layer 7
Routing style IP and port Host and path
TLS termination Usually app-specific Can terminate at the edge
Primary use Stable access to Pods HTTP/HTTPS application entry routing
A Service is still part of the path even when Ingress is used; Ingress does not replace Services internally.
Use It Well

Practice and Real-World Thinking

One entry point for many apps

Use Ingress to expose multiple web apps behind one edge endpoint.

TLS at the edge

Centralize HTTPS handling instead of configuring certificates in every app.

Annotations for fine-tuning

Use controller-specific annotations for rate limiting, redirects, timeouts, and other edge behavior.