Ingress Controllers

Analogy categoryAnalogies

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.

yaml

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: 8080

TLS 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.

yaml

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: 80

When 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?

Horizontal Pod Autoscaling

Related Study Notes in DevOps

Browse all study notes

DevOps

Nginx Study Notes

DevOps · 30 topics

DevOps

Ansible Study Notes

DevOps · 30 topics

DevOps

Advanced Kubernetes Study Notes

Kubernetes · 30 topics

DevOps

Advanced Bash Scripting Study Notes

Bash · 30 topics

DevOps

Apache Kafka Study Notes

Kafka · 30 topics

DevOps

CI/CD Tools & Pipelines Study Notes

YAML · 37 topics

Topics covered

#YAML#DockerKubernetesStudyNotes#DevOps#IngressControllers#Ingress#Controllers#Routing#HTTP#StudyNotes#SkillVeris

Routing HTTP Traffic into the Cluster

Ingress Resources vs. Ingress Controllers

Host- and Path-Based Routing

TLS Termination

Practice what you learned

You May Also Like

Related Reading

Related Study Notes in DevOps

Topics covered