Ingress controllers in Kubernetes are a bit like the bouncers at a club for your network traffic, deciding who gets in and where they go. Nginx and Traefik are two of the most popular bouncers, and they’ve got different styles.
Here’s Traefik managing traffic for a simple web app. We’ve got a Deployment for our app, and then we define a Traefik IngressRoute resource. Notice how it points directly to the service name (my-app-service) and the port (80).
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
name: my-app-ingress
spec:
entryPoints:
- web
routes:
- match: Host(`myapp.example.com`)
kind: Rule
services:
- name: my-app-service
port: 80
When a request for myapp.example.com hits Traefik, it consults this IngressRoute and forwards the request to my-app-service on port 80. It’s straightforward. Traefik’s magic is its dynamic configuration. It watches Kubernetes API resources (like IngressRoute, Service, Endpoint) and updates its routing table on the fly without needing a restart.
Now, let’s look at Nginx. For a similar setup, you’d typically use a standard Kubernetes Ingress resource.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-app-ingress
spec:
rules:
- host: myapp.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: my-app-service
port:
number: 80
Nginx Ingress Controller also watches Kubernetes resources, but it primarily relies on the Ingress object. When Nginx receives a request for myapp.example.com, it checks its internal configuration (generated from the Ingress object) and routes it to my-app-service on port 80.
The core problem both solve is exposing internal Kubernetes services to the outside world in a structured, configurable way. They handle TLS termination, load balancing, path-based routing, and host-based routing. You don’t want to expose each pod directly; you want a single entry point that intelligently distributes traffic.
Internally, Traefik uses a v2 configuration format that’s very flexible. It has concepts like Routers, Services, and Middlewares. Routers define how requests are matched (host, path, headers), Services define where traffic goes (Kubernetes Service, external URL, etc.), and Middlewares are pieces of logic that can be applied to requests before they reach the service (like rate limiting, authentication, or header manipulation). This modularity is a big part of its appeal.
Nginx, on the other hand, is built on the battle-hardened Nginx web server. Its configuration is translated into Nginx’s own nginx.conf format. While it supports many features, the configuration often feels more like traditional Nginx configuration, which can be a pro for those familiar with Nginx but a con for those who prefer a more Kubernetes-native API. The Nginx Ingress Controller typically uses a ConfigMap for global settings and annotations on the Ingress resource for per-route configurations.
Here’s where Traefik really shines: automatic TLS certificate management with Let’s Encrypt. You can configure Traefik to automatically obtain and renew certificates.
apiVersion: traefik.containo.us/v1alpha1
kind: TLSStore
metadata:
name: default
spec:
defaultCertificate:
secretName: my-tls-secret # Fallback certificate
---
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
name: my-app-ingress-tls
spec:
entryPoints:
- websecure
routes:
- match: Host(`myapp.example.com`)
kind: Rule
services:
- name: my-app-service
port: 80
tls:
certResolver: myresolver # This tells Traefik to use Let's Encrypt
stores:
- default
When Traefik sees an IngressRoute with a tls section pointing to a certResolver, it automatically tries to get a certificate for that host. This simplifies operations significantly. Nginx Ingress Controller can also do TLS, but it typically requires you to manually create and manage Kubernetes Secrets containing your certificates.
The one thing most people don’t realize about Ingress controllers is their ability to act as API Gateways. While they are primarily for routing HTTP/S traffic, both Traefik and Nginx Ingress can be extended with custom middlewares or configurations to perform advanced actions like authentication (OAuth2, JWT), rate limiting, request transformation, and even service mesh-like functionalities. This blurs the line between a simple load balancer and a full-blown API gateway, often without needing a separate tool.
The next step after mastering Ingress is to explore how you might deploy services that don’t need to be exposed externally, or how to manage traffic between services within your cluster.