Introduction to Ingress: Kubernetes Routing Explained

Previously in this course, we explored The Role of Services and learned how to expose applications using Exposing Apps with NodePort. While those methods work for simple internal communication or quick testing, they don't scale well for production web traffic.

In this lesson, we introduce Ingress, the standard Kubernetes resource for managing external access to HTTP and HTTPS services.

What is Ingress?

At its core, Ingress is an API object that manages external access to services in a cluster, typically via HTTP. Unlike a Service, which acts as a simple load balancer for internal Pods, an Ingress provides advanced routing capabilities.

Think of an Ingress as a "smart router" that sits at the edge of your cluster. It inspects incoming HTTP requests and decides where to send them based on rules you define. You can route traffic based on the URL path (e.g., example.com/api vs. example.com/web) or the hostname (e.g., api.example.com vs. app.example.com).

Why not just use NodePort or LoadBalancer?

You’ve already seen how to expose apps, but those approaches have significant limitations:

Using a LoadBalancer service for every microservice is a fast way to burn through your cloud provider's budget and IP address limits. Ingress solves this by allowing you to expose multiple services through a single public-facing entry point.

The Ingress Architecture

To understand Ingress, you must distinguish between the Ingress Resource and the Ingress Controller.

1. The Ingress Resource: A YAML manifest where you define your routing rules. It’s just a configuration file that says, "Send traffic for /api to the backend-service."
2. The Ingress Controller: A specialized Pod (usually NGINX, HAProxy, or Traefik) that watches the API server for Ingress resources. It then configures its own internal proxy settings to enforce those rules.

Without an Ingress Controller, the Ingress resource is just a piece of paper; it does absolutely nothing.

A Concrete Example

Imagine you have two services: order-service and product-service. You want users to access them via the same domain. Your Ingress manifest would look something like this:

YAML
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
spec:
  rules:
  - host: myapp.com
    http:
      paths:
      - path: /orders
        pathType: Prefix
        backend:
          service:
            name: order-service
            port:
              number: 80
      - path: /products
        pathType: Prefix
        backend:
          service:
            name: product-service
            port:
              number: 80

When a request arrives at myapp.com/orders, the Ingress Controller sees the rule, strips the path, and forwards the request to your order-service. This effectively allows you to build a complex API gateway using native Kubernetes configuration.

Hands-on Exercise

To prepare for our upcoming installation, observe your current environment. Since we haven't installed a controller yet, check if any resources are present:

1. Run kubectl get ingress -A.
2. Observe the output. If you are on a standard local cluster (like Minikube or Kind), you might see nothing or a "No resources found" message.
3. This is expected. An Ingress resource requires a controller to "reconcile" the state of your cluster.

Common Pitfalls

• Forgetting the Controller: Many beginners write an Ingress manifest and get frustrated when it doesn't work. Remember: the Ingress resource is declarative configuration, not the networking logic itself. You must have a controller running.
• Path Type Confusion: Using Exact vs Prefix path types often causes 404 errors. Prefix is generally safer for routing to services, as it allows for sub-paths.
• Security Misconfiguration: Because Ingress handles the TLS termination (HTTPS), ensure your certificates are managed correctly. A misconfigured Ingress can leave your traffic exposed in plain text.

Frequently Asked Questions

Does Ingress work with non-HTTP traffic (like databases)? No. Standard Ingress is designed for Layer 7 (HTTP/HTTPS). For TCP/UDP traffic, you generally need to use a LoadBalancer service or a specialized service mesh.

Can I have multiple Ingress Controllers? Yes. You can specify which controller should handle a specific Ingress resource using an ingressClassName field in the spec.

Is Ingress better than a Service Mesh? Ingress is for "North-South" traffic (outside to inside). A Service Mesh is typically for "East-West" traffic (inside the cluster, service-to-service). They often complement each other.

Recap

Ingress is the most efficient way to manage external HTTP routing in Kubernetes. By using a single Ingress Controller to handle routing for multiple services, you reduce infrastructure costs and simplify your network topology. We've contrasted this with NodePort and LoadBalancer, noting that Ingress provides the L7 awareness necessary for modern web applications.

Up next: Setting Up an Ingress Controller, where we will deploy an NGINX controller to bring our routing rules to life.