Routing HTTP Traffic into the Cluster
While a Service of type LoadBalancer exposes one application per external IP, most clusters need to route HTTP/HTTPS traffic for many hostnames and paths through a single entry point. Ingress provides this Layer-7 routing layer, but it requires an Ingress controller — a separate piece of software like NGINX Ingress Controller or Traefik — actually running in the cluster to implement the rules.
Cricket analogy: A single stadium gate (LoadBalancer) can only funnel fans to one match; Ingress is like a stadium complex router that sends fans to the right ground based on which team they follow, but you still need turnstile staff (NGINX or Traefik) actually operating the gates.
Ingress Resources vs. Ingress Controllers
An Ingress object is just a declarative set of routing rules; it does nothing on its own. The Ingress controller watches the API server for Ingress objects and configures an underlying reverse proxy (or cloud load balancer) to match. Without a controller installed, Ingress resources have no effect.
Cricket analogy: A team sheet listing batting order does nothing until the twelfth man actually enters it into the scorer's system; the Ingress object is the team sheet, and the controller is the scorer who watches for new sheets and updates the scoreboard.
Host- and Path-Based Routing
Ingress rules can route based on the request's Host header, its URL path, or both, allowing multiple applications to share a single external IP and load balancer.
Cricket analogy: Ingress routing by Host header and path is like a stadium director sending IPL fans to Wankhede for 'mumbaiindians.com' and to Eden Gardens for 'kkr.com', all reachable from one shared ticketing IP.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: web-ingress
namespace: production
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
ingressClassName: nginx
rules:
- host: shop.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: shop-frontend-svc
port:
number: 80
- host: api.example.com
http:
paths:
- path: /v1
pathType: Prefix
backend:
service:
name: api-svc
port:
number: 8080TLS Termination
Ingress can terminate TLS by referencing a Secret of type kubernetes.io/tls containing the certificate and private key, so the controller handles HTTPS and forwards plain HTTP internally to the backend Service.
Cricket analogy: Ingress terminating TLS is like security screening happening only at the stadium's outer gate using a gate pass stored like a Secret; once inside past the controller, fans move freely to the concession stands (backend Service) over trusted plain internal paths without re-checking tickets.
spec:
tls:
- hosts:
- shop.example.com
secretName: shop-tls-cert
rules:
- host: shop.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: shop-frontend-svc
port:
number: 80When multiple Ingress controllers run in the same cluster, ingressClassName tells Kubernetes which controller should implement a given Ingress resource, referencing an IngressClass object such as { apiVersion: networking.k8s.io/v1, kind: IngressClass, metadata: { name: nginx }, spec: { controller: k8s.io/ingress-nginx } }.
pathType can be Exact (must match the path exactly), Prefix (matches based on a URL path segment prefix), or ImplementationSpecific (behavior defined by the controller) — Prefix is the most commonly used.
Ingress only handles HTTP/HTTPS (Layer 7) traffic. For raw TCP/UDP traffic, you need controller-specific extensions (like NGINX's tcp-services ConfigMap) or a Service of type LoadBalancer instead.
- An Ingress resource defines routing rules; an Ingress controller (e.g., NGINX, Traefik) enforces them.
- Ingress supports host-based and path-based routing to different backend Services.
- TLS termination is configured via spec.tls referencing a kubernetes.io/tls Secret.
- ingressClassName selects which controller handles a given Ingress when several are installed.
- pathType (Exact, Prefix, ImplementationSpecific) governs how paths are matched.
- Ingress is Layer 7 (HTTP/HTTPS) only — TCP/UDP needs LoadBalancer Services or controller extensions.
Practice what you learned
1. What is required for an Ingress resource to actually route traffic?
2. How does Ingress typically route requests to different backend Services?
3. How is TLS termination configured on an Ingress resource?
4. What is the purpose of ingressClassName in an Ingress spec?
5. Which type of traffic can standard Kubernetes Ingress NOT route by itself?
Was this page helpful?
You May Also Like
Services and Networking
Understand how Kubernetes Services provide stable networking identities and load balancing for ephemeral, dynamically scheduled Pods.
Horizontal Pod Autoscaling
Learn how the HorizontalPodAutoscaler automatically adjusts replica counts based on CPU, memory, or custom metrics to match workload demand.
Kubernetes Security Basics
Learn defensive Kubernetes security fundamentals: RBAC, NetworkPolicies, Pod security context, secrets handling, and image scanning.
Blue-Green and Canary Deployments
How to safely release new application versions to production using zero-downtime blue-green switches and gradual canary rollouts.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsCI/CD Tools & Pipelines Study Notes
YAML · 37 topics