Comparing Common Ingress Controllers

This time let's compare some of the ingress components frequently used in k8s clusters. Ingress serves as the entry point for HTTP and HTTPS traffic into the cluster. It can route traffic to different Services inside a Kubernetes cluster, providing load balancing and traffic control.

Why Ingress Matters

By default, services in a cluster can only reach each other from inside the cluster. The most direct ways to expose a service externally are NodePort or LoadBalancer Services, but both have limitations: NodePort has a restricted port range and makes domain and path management awkward, while LoadBalancer consumes one load balancer per exposed service—which on a cloud provider means real money.

Ingress solves exactly this: a single unified entry point receives all external HTTP/HTTPS traffic and dispatches it to the cluster's Services by hostname and path. Which Ingress controller you choose directly shapes the day-to-day experience of routing configuration, TLS management, and layer-4 exposure, so it's worth lining up the mainstream options side by side at selection time.

How It Works

Ingress works by mapping HTTP and HTTPS requests onto Services. In Kubernetes, a Service is the resource object that routes traffic to Pods. When Ingress receives an external HTTP or HTTPS request, it matches the hostname and path in the request against the Ingress rules and routes the request to the corresponding Service.

Here's a point that trips people up: the Ingress resource itself is just a declarative routing rule—writing one does not make anything happen on its own. The real work is done by the Ingress controller. It runs in the cluster as Pods, continuously watches the API Server for changes to Ingress, Service, Endpoint, and other resources, translates those rules into configuration for its underlying proxy (Nginx, Envoy, or Traefik's built-in proxy, for example), and hot-reloads it into effect. In other words:

1. Ingress resource: declares "which path of which hostname forwards to which Service";
2. Ingress controller: watches for rule changes, generates and loads the proxy configuration;
3. Underlying proxy: actually receives external requests and forwards them.

When matching a request, the controller first matches the virtual host by Host, then matches routing rules by Path, and finally forwards the request to the Pods behind the corresponding Service. TLS certificates are typically attached to Ingress rules as Secrets, and the controller handles TLS termination at the edge.

Common Ingress Controllers

To use Ingress, you must install an Ingress controller first. Kubernetes does not ship a default one, but there are many third-party controllers to choose from:

A quick take on the trade-offs of the common options:

1. Nginx Ingress Controller: the community's most common choice, built on Nginx as a reverse proxy, with rich documentation and case studies. Much of its configuration is done via annotations. A solid default option;
2. Traefik: ships with a dashboard, applies configuration dynamically without an Nginx-style reload, and integrates smoothly with Let's Encrypt for automatic certificate issuance;
3. Istio Ingress Gateway: if the cluster is already running the Istio service mesh, using its Gateway as the entry point ties in with in-mesh traffic governance (canary rollouts, circuit breaking, telemetry)—but pulling in Istio just for an entry point is far too heavy;
4. Others like HAProxy and Kong each lean into performance and API gateway capabilities respectively.

The selection logic can be plain and simple: with no special requirements, go with Nginx Ingress; if you want dynamic configuration and a more modern operations experience, look at Traefik; if you're already on a service mesh, just use the mesh's own Gateway.

Exposing Layer-4 Services

We often want to expose services outside the cluster beyond layer-7 HTTP—some run on layer-4 protocols, such as MySQL, Redis, and MongoDB.

However, the Kubernetes Ingress specification itself only supports HTTP and HTTPS, so default Ingress controllers only support these two protocols. Some third-party Ingress controllers, though, can be extended to expose TCP and UDP.

1. Traefik: Traefik supports exposing TCP by specifying traefik.tcp.routers and traefik.tcp.services in the routing rules to configure TCP services and routes.
2. Istio: Istio is a service mesh framework whose Ingress Gateway component supports exposing TCP. You configure TCP services and routes by defining a VirtualService against the Ingress Gateway.

One addition: the Nginx Ingress Controller can also expose TCP/UDP services. The approach is to maintain two ConfigMaps, tcp-services and udp-services, containing the "external port → namespace/Service:port" mappings, then open the corresponding ports on the controller's Service. This bypasses the Ingress resource entirely—it's the controller's own extension mechanism.

Layer-4 exposure differs fundamentally from layer-7: TCP has no notion of Host or Path, so you cannot distinguish backends by hostname the way HTTP does—only by port number. Every exposed TCP service therefore consumes one port at the entry point, and port management gets fiddly as services multiply.

Pitfalls and Caveats

1. If you create an Ingress resource and nothing happens, most likely no controller is installed in the cluster, or the ingressClassName on the Ingress doesn't match the controller—an especially easy trap when multiple controllers run in one cluster;
2. Be careful exposing database services (MySQL, Redis, etc.) to the public internet through Ingress: layer-4 forwarding adds no authentication hardening. Safer options are the internal network, a VPN, or a bastion host;
3. Annotations are not portable across controllers. When migrating from Nginx to Traefik, every rewrite, rate-limit, and timeout previously configured via annotations must be translated one by one;
4. For long-lived layer-4 connections, watch the proxy's idle timeout: the default is often shorter than what database client connection pools expect, and connections can get cut off mid-flight.

Wrap-up

Ingress is the unified entry point for north-south traffic in the cluster: rules are declared by Ingress resources, and the actual forwarding is done by the controller. For layer-7 scenarios, any of the mainstream controllers will do the job—the differences lie mainly in configuration style and ecosystem. Layer-4 exposure goes beyond the Ingress spec itself and relies on each vendor's own extension mechanism, whether Traefik, Istio Gateway, or Nginx Ingress's ConfigMaps. Choosing based on your team's existing stack and operational habits is more practical than chasing feature lists.