Nginx vs Traefik Ingress Controller — HTTP/HTTPS Routing for Production Kubernetes

The Problem of Exposing Services in Kubernetes

If you run a production Kubernetes cluster, you know that exposing each service with a LoadBalancer or NodePort is wasteful: multiple public IPs, higher costs, and messy port management. At Meteora Web, we've seen AWS bills of $300/month just for public IPs. A single Ingress controller solves this: one LoadBalancer, intelligent routing.

An Ingress controller listens on standard ports (80, 443) and forwards traffic to internal Services based on rules defined in Ingress resources. The choice between Nginx Ingress Controller and Traefik isn't trivial. This guide explains how they work and when to pick each.

What's the difference between an Ingress controller and a standard LoadBalancer Service?

A LoadBalancer Service creates an external load balancer per service – cost scales linearly. An Ingress controller runs as a pod (or multiple) that implements routing rules. A single LoadBalancer points to it, and the controller decides the destination based on hostname and path.

Economic benefit: one public IP for all services. The controller can also handle TLS termination, rate limiting, authentication, rewrite rules, and canary releases centrally.

Example Ingress resource with Nginx

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-app
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
spec:
  ingressClassName: nginx
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80
      - path: /
        pathType: Prefix
        backend:
          service:
            name: frontend-service
            port:
              number: 3000

Traffic to app.example.com goes through the Nginx controller, which redirects to HTTPS and maps paths – no extra LoadBalancers.

How does routing work in Nginx Ingress Controller vs Traefik?

Both support host‑based, path‑based, headers, and method routing. The differences lie in architecture and advanced features.

Nginx Ingress Controller

Based on C‑Nginx, it's lightweight and extremely fast. Native features:

• Path rewriting
• Rate limiting via annotations
• Basic auth and OAuth2 proxy
• Sticky sessions
• Configuration via ConfigMap and annotations

We use it for latency‑sensitive workloads. One e‑commerce client migrated 8 microservices to Nginx Ingress – average response time dropped 15% by eliminating an extra proxy layer.

Traefik

Written in Go, cloud‑native, with built‑in UI and multi‑provider support (K8s, Docker, Consul, etc.). Key features:

• Composable middlewares (rate limit, retry, circuit breaker, redirect)
• Auto‑discovery via labels
• Integrated dashboard
• Native Let's Encrypt ACME support
• Easier integration with Consul or Vault

With Traefik, you define middlewares as separate reusable resources. With Nginx you repeat annotations (or use snippets). For environments with dozens of services and complex rules, Traefik reduces duplication.

Which one should you choose for production?

It depends on your team, complexity, and cost model. We've used both on real projects.

Nginx Ingress: when it fits

• Team already knows Nginx and needs raw performance
• Very high throughput (tens of thousands req/s)
• Prefer minimal configuration via annotations
• Already have Prometheus monitoring to consume exposed metrics

Traefik: when to prefer it

• Stack includes Docker Compose, Nomad, or other orchestrators
• Want a graphical dashboard for debugging
• Need complex middlewares (JWT, IP whitelist) across many services
• Team prefers declarative CRDs over annotation‑heavy YAML

Real case: for a logistics client we chose Traefik because they needed OIDC authentication per path, global rate limiting, and a dashboard. With Nginx we would have needed oauth2-proxy and lua scripts; Traefik handled it natively.

How to set up automatic HTTPS with Let's Encrypt on Nginx and Traefik?

TLS is mandatory for production. Both controllers support cert-manager or built‑in ACME.

cert-manager + Nginx Ingress

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: admin@example.com
    privateKeySecretRef:
      name: letsencrypt-prod
    solvers:
    - http01:
        ingress:
          class: nginx

Add annotation to Ingress resource:

metadata:
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"

Traefik with built‑in ACME

Configure in Traefik's static config (or CRD):

certificatesResolvers:
  letsencrypt:
    acme:
      email: admin@example.com
      storage: /data/acme.json
      httpChallenge:
        entryPoint: web

In IngressRoute set tls.certResolver: letsencrypt. No external cert-manager needed.

We prefer cert-manager because it's controller‑agnostic and reusable across all K8s resources.

Common routing mistakes

• Path normalization: Without rewrite-target (Nginx), the original path hits the backend service – may cause 404s.
• SSL not enforced: Always add redirect to HTTPS.
• Proxy‑buffers or body size limits: A client lost large uploads because default proxy-body-size was 1 MB.
• Ignoring controller healthchecks: Without readiness probes, the controller can terminate traffic while the pod is still live.

What to do next

1. Choose your controller: Nginx for raw speed and Nginx expertise; Traefik for dashboard, declarative middlewares, multi‑orchestrator.
2. Deploy via Helm: Use the official chart (ingress-nginx or traefik/traefik). Set up a single LoadBalancer with a static IP.
3. Install cert-manager (unless using Traefik's built‑in ACME) and create a ClusterIssuer for Let's Encrypt.
4. Add annotations to all Ingress resources: HTTPS redirect, rewrite target, rate limits.
5. Test with curl: curl -I http://your-domain.com should return 301 → HTTPS → 200.
6. Enable monitoring: expose Prometheus metrics; build a Grafana dashboard for latency, errors, traffic per host.

For deeper context, check our Kubernetes Pillar Guide and CD Pipeline article.

We at Meteora Web work with production Kubernetes clusters since 2017. Need a cost‑performance review of your ingress setup? Contact us.