Ingress Controllers

[!NOTE] This module explores the core principles of Ingress Controllers, deriving solutions from first principles and hardware constraints to build world-class, production-ready expertise.

1. The Problem: Cost & Complexity

Using LoadBalancer for every service is expensive. If you have 50 microservices, paying for 50 AWS Load Balancers is not sustainable.

You want One LoadBalancer that sits at the edge and routes traffic based on the URL (e.g., api.example.com vs web.example.com). This is Layer 7 routing.

2. The Solution: Ingress

Ingress is not a Service type. It’s a configuration object that defines rules for external access.

To make Ingress work, you need an Ingress Controller.

1. The Controller: A specialized Pod (usually Nginx, Traefik, or HAProxy) that runs as a reverse proxy.
2. The Resource: A YAML file defining routing rules.
3. The Flow: The Controller watches Ingress resources and automatically updates its internal configuration (e.g., nginx.conf).

---

3. Interactive: Routing Simulator

Simulate how an Ingress Controller routes traffic based on Host headers and URL paths.

→

Ingress (Nginx)

Router

→

API Service

Web Service

Blog Service

---

4. Code Example: Ingress Resource

This configuration defines the routing rules shown above.

Ingress YAML

TLS Ingress YAML

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  rules:
  # Host-based routing
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-svc
            port:
              number: 80
  - host: web.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-svc
            port:
              number: 80
  # Path-based routing (same host)
  - host: example.com
    http:
      paths:
      - path: /blog
        pathType: Prefix
        backend:
          service:
            name: blog-svc
            port:
              number: 80

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: secure-ingress
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - api.example.com
    secretName: api-tls-cert # Must contain tls.crt and tls.key
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-svc
            port:
              number: 80

5. TLS Termination

Ingress is the standard place to handle SSL/TLS termination.

1. Create a Kubernetes Secret containing your certificate and key.
2. Reference it in the tls section of the Ingress.
3. The Ingress Controller (Nginx) will handle the SSL handshake and forward unencrypted HTTP traffic to your internal Pods.

[!TIP] Cert-Manager: In production, use cert-manager to automatically provision and renew Let’s Encrypt certificates for your Ingress resources.