Understanding Ingress Controllers

We've just examined the Ingress resource in detail – how it defines rules for routing external HTTP/S traffic based on hosts and paths, and how it configures TLS termination. However, a critical point to understand is that the Ingress resource itself is just data. It's a configuration object stored in the Kubernetes API server, describing how you want traffic to be routed. By itself, it doesn't actually do anything to implement those rules.

So, what actually reads these Ingress resources and makes the routing happen? That's the job of an Ingress Controller.

What is an Ingress Controller?

An Ingress Controller is a dedicated application (or set of applications) running within your Kubernetes cluster that actively monitors the Kubernetes API server for Ingress resources (along with related Services, Endpoints, and Secrets). When it detects changes to these resources, it translates the desired routing rules defined in the Ingress object into actual, low-level configuration for a real load balancer or reverse proxy that it manages.

Think of it as a specific type of Kubernetes controller focused on L7 ingress traffic management:

1. Watch: The Ingress Controller watches the Kubernetes API for Ingress, Service, Endpoints, Secret (for TLS), and potentially IngressClass resources.

2. Translate: When an Ingress resource is created or updated (and matches the controller's configured class, e.g., via ingressClassName), the controller reads its spec.rules, spec.tls, etc.

3. Configure: It dynamically generates the necessary configuration for the underlying proxy/load balancer it controls (e.g., Nginx nginx.conf, Traefik dynamic configuration, HAProxy config). This configuration tells the proxy how to route incoming requests based on hostname, path, and handle TLS termination using the specified certificates.

4. Expose: The proxy managed by the Ingress Controller is typically exposed to the outside world, often via a Service of type: LoadBalancer or type: NodePort. External traffic hits this exposed entry point first.

Why is an Ingress Controller Necessary?

Kubernetes core is designed to be extensible and doesn't mandate a specific L7 load balancing solution. The base installation doesn't come with a built-in component that can natively handle sophisticated HTTP/S routing based on hostnames and paths.

The Ingress resource provides the standardized API for defining L7 routing needs, but Kubernetes leaves the implementation of that routing to specialized controllers. This allows users to choose the Ingress Controller that best fits their needs based on factors like:

• Performance requirements

• Specific features (e.g., advanced rewrites, authentication methods, WAF integration, gRPC/WebSocket support)

• Underlying proxy technology preference (Nginx, Envoy, HAProxy, etc.)

• Vendor support or integration with cloud provider services

Without an Ingress Controller running in your cluster, creating an Ingress resource will have no effect – no routing rules will be implemented, and no external traffic will be directed based on those rules.

Common Ingress Controllers:

There are many popular Ingress Controllers available, including:

• ingress-nginx: Managed by the Kubernetes community, uses Nginx as the reverse proxy. Very popular and feature-rich.

• Traefik Kubernetes Ingress Provider: Uses Traefik proxy, known for its ease of use and automatic configuration features.

• HAProxy Ingress: Uses the HAProxy load balancer.

• Contour: Uses Envoy proxy, often associated with service mesh concepts.

• Cloud Provider Specific Controllers: AWS Load Balancer Controller, GCE Ingress, Azure Application Gateway Ingress Controller integrate deeply with their respective cloud load balancers.

• Istio Ingress Gateway, Linkerd Edge Router: Service mesh components often provide their own ingress gateway functionality.

The Role of IngressClass and ingressClassName

To allow multiple Ingress Controllers to coexist within a single cluster (e.g., one for public traffic, one for internal), the IngressClass resource and the spec.ingressClassName field in the Ingress resource were introduced.

• An administrator typically creates IngressClass resources, naming them (e.g., "nginx-public", "traefik-internal") and specifying which controller implementation they correspond to (spec.controller).

• When you create an Ingress resource, you set spec.ingressClassName to the name of the IngressClass you want to handle it.

• Each Ingress Controller is configured to only pay attention to Ingress resources that specify its designated IngressClassName.

In Summary:

You cannot use Ingress resources effectively without first choosing, deploying, and configuring an appropriate Ingress Controller within your Kubernetes cluster. The controller is the engine that reads your Ingress configuration and makes the desired HTTP/S routing a reality by configuring an underlying proxy/load balancer. When we programmatically create Ingress objects using client-go, we are creating the configuration that an already-running Ingress Controller will consume and act upon.