Ingress: HTTP Routing

Key Takeaways for AI & Readers

• Centralized Routing: Ingress allows multiple services to share a single IP and Load Balancer by routing traffic based on hostnames or paths.
• Resource vs. Controller: An Ingress resource is just a set of rules; an Ingress Controller (like NGINX) is the actual workload that executes those rules.
• Path Matching: Use "Exact" or "Prefix" matching to control how sub-paths are handled, and "Rewrite Target" annotations to strip prefixes before they reach your app.
• TLS Termination: Ingress is the standard layer for managing SSL certificates, often automated with tools like cert-manager.

Services (ClusterIP) are great for internal traffic. LoadBalancers are great for exposing a single app. But what if you have 50 microservices? You don't want to pay for 50 Cloud Load Balancers ($$$).

Ingress solves this. It exposes multiple services under a single IP address, using Host-based and Path-based routing.

Interactive Routing Simulator

Test how an Ingress routes traffic based on the URL path (/ vs /api).

Simulate Request Path

https://example.com

🌍 Internet

🚦 Ingress Controller

Service: Web

Service: API

Pod: Web

Pod: API

React Flow

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

Try entering /api/v1/users to hit the API service, or /about to hit the Web service.

---

1. The Architecture

Ingress is unique because creating the resource (kind: Ingress) does nothing by itself. You need a Controller running in the cluster.

The Ingress Controller

A special Pod (usually NGINX, Traefik, HAProxy, or Istio) that:

1. Listens on ports 80/443.
2. Watches the API Server for Ingress resources.
3. Dynamically updates its own configuration file (e.g., nginx.conf) to route traffic to your backend Pods.

Analogy: The Ingress Resource is the "configuration file", and the Controller is the "web server" that executes it.

---

2. Routing Rules

Path Types

• Exact: URL must match exactly. /foo matches /foo but not /foo/bar.
• Prefix: Matches sub-paths. /foo matches /foo/bar. Note: This handles the "trailing slash" ambiguity automatically.

Host-Based Routing

You can host multiple domains on one Ingress.

spec:
  rules:
  - host: api.example.com
    http: ... (sends to API service)
  - host: web.example.com
    http: ... (sends to Web service)

---

3. TLS & Security

Ingress is the standard place to terminate SSL/TLS.

1. Create a Kubernetes Secret containing your tls.crt and tls.key.
2. Reference it in the Ingress:

spec:
  tls:
  - hosts:
    - example.com
    secretName: my-tls-secret

Pro Tip: Use cert-manager. It automatically talks to Let's Encrypt, generates valid certificates, and updates the Kubernetes Secret for you.

---

4. Ingress Classes

What if you have NGINX for internal tools and AWS ALB for public traffic? You use ingressClassName.

spec:
  ingressClassName: nginx-internal

---

5. Troubleshooting 404s

If you get a 404, who is generating it?

The "Rewrite Target" Problem

Often, your Ingress listens on /api, but your application expects requests on /.

• Result: A request to example.com/api/users reaches your app as GET /api/users. Your app returns 404 because it only knows /users.
• Fix: Use the nginx.ingress.kubernetes.io/rewrite-target: / annotation. This "strips" the prefix before sending it to the pod.

404 Source Check

1. Default Backend 404: The Ingress Controller received the request but found no matching rule.
   • Fix: Check your host header and path.
2. Application 404: The Ingress successfully routed traffic to your Pod, but your App returned 404.
   • Fix: Check your App logs. Does your App expect the /api prefix or does it expect it to be stripped? (See rewrite-target annotations).