Ingress Controller Nginx e Traefik — Routing HTTP/HTTPS in Kubernetes per la Produzione Sicura

Il problema dei servizi esposti in Kubernetes

Se gestisci un cluster Kubernetes in produzione, sai bene che esporre più servizi all'esterno con LoadBalancer o NodePort è inefficiente. Ogni servizio ha un IP pubblico (e costa) o devi ricordarti porte strane. Noi, di Meteora Web, abbiamo visto cluster con 12 servizi esposti via LoadBalancer su AWS: bolletta da 300 $ al mese solo di IP pubblici. Un ingresso unico, con routing basato su hostname e path, risolve tutto: un solo LoadBalancer condiviso.

Un Ingress controller fa da proxy intelligente: ascolta su porte standard (80 e 443) e instrada il traffico verso i Service interni in base alle regole definite nelle risorse Ingress. Ma la scelta tra Nginx Ingress Controller e Traefik non è scontata: ognuno ha punti di forza, compromessi e anelli deboli. In questa guida vediamo come funzionano e quando usare l'uno o l'altro.

Qual è la differenza tra un Ingress controller e un Service LoadBalancer standard?

Un Service di tipo LoadBalancer (su cloud) crea un bilanciatore esterno per ogni servizio. Scalare significa moltiplicare IP e costi. Un Ingress controller, invece, è un pod (o più) che implementa le regole di routing definite nelle Ingress resource. Un unico LoadBalancer (spesso di tipo Layer 4) punta al controller, che poi decide il Service di destinazione in base a hostname e path.

Vantaggio economico: paghi un solo IP pubblico. In più, il controller può gestire terminazione TLS, rate limiting, autenticazione, rewrite, canary release e molto altro, centralizzando operazioni che altrimenti dovresti configurare su ogni servizio.

Esempio di risorsa Ingress con 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.esempio.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

Con questa configurazione, tutto il traffico verso app.esempio.com passa per il controller Nginx, che reindirizza HTTPS e mappa i path. Nessun LoadBalancer aggiuntivo.

Come funziona il routing di Nginx Ingress Controller rispetto a Traefik?

Entrambi i controller supportano routing basato su host, path, headers, e metodi HTTP. La differenza sta nell'architettura e nelle feature avanzate.

Nginx Ingress Controller

Basato su Nginx (C), è leggero e velocissimo. Supporta nativamente:

• Rewrite del path (es. /api/v1/orders → api-service/orders)
• Rate limiting con annotazioni
• Autenticazione di base e OAuth2 proxy
• Sticky session
• Configurazione tramite ConfigMap e annotazioni

Noi lo usiamo per carichi critici perché la latenza è bassissima e l'ecosistema è maturo. Un nostro cliente e-commerce ha migrato 8 microservizi su Nginx Ingress – il tempo di risposta medio è sceso del 15% perché abbiamo eliminato un livello di proxy aggiuntivo.

Traefik

Scritto in Go, nato cloud‑native, offre UI integrata, supporto per più provider (K8s, Docker, Consul, etc.) e una configurazione via CRD (Custom Resource Definition) più dichiarativa. Tra le feature distintive:

• Middleware componibili (rate limit, retry, circuit breaker, redirect, etc.)
• Auto-discovery dei servizi tramite label
• Dashboard web integrata per monitoraggio
• Supporto nativo a Let's Encrypt con ACME
• Più semplice da integrare con strumenti come Consul o HashiCorp Vault

La differenza pratica: con Traefik puoi descrivere middlewares come risorse separate e riutilizzarli su più Ingress. Con Nginx devi ripetere annotazioni su ogni risorsa (o usare snippet). Per ambienti con decine di servizi e regole complesse, Traefik può ridurre la duplicazione.

Quale scegliere per il proprio cluster in produzione?

La risposta dipende da: budget operativo, complessità, e competenze del team. Noi abbiamo usato entrambi su progetti reali.

Nginx Ingress: quando va bene

• Hai un team che conosce Nginx e vuole prestazioni pure
• Devi gestire carichi altissimi (decine di migliaia di richieste al secondo)
• Preferisci configurazioni minimali via annotazioni
• Hai già un setup di monitoring con Prometheus e vuoi sfruttare le metriche esposte

Traefik: quando preferirlo

• Il tuo stack include Docker Compose, Nomad, o altri orchestratori (oltre K8s)
• Vuoi una dashboard grafica integrata per debugging
• Devi configurare middlewares complessi (es. rate limiting per IP, JWTs, whitelist) su più servizi
• Il team preferisce CRD dichiarativi rispetto a YAML con annotazioni

Un dato concreto: in una nostra implementazione per un cliente logistico, abbiamo scelto Traefik perché aveva bisogno di autenticazione per ogni path (con OIDC), rate limiting globale e dashboard per il monitoring. Con Nginx avremmo dovuto configurare vari moduli esterni (oauth2-proxy, lua‑scripts). Con Traefik è stato tutto nativo.

Come configurare HTTPS automatico con Let's Encrypt su Nginx e Traefik?

La sicurezza del routing HTTPS è un must per qualsiasi esposizione pubblica. Entrambi i controller supportano cert-manager per ottenere certificati Let's Encrypt automatici.

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@esempio.com
    privateKeySecretRef:
      name: letsencrypt-prod
    solvers:
    - http01:
        ingress:
          class: nginx

Poi aggiungi l'annotazione alla risorsa Ingress:

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

Traefik con ACME integrato

Traefik ha un resolver ACME integrato. Basta configurare nel file di configurazione (o tramite CRD):

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

Poi nella risorsa IngressRoute (CRD di Traefik) specifichi tls.certResolver: letsencrypt. Senza cert-manager esterno.

Noi preferiamo cert-manager perché è indipendente dal controller e permette di usare lo stesso issuer per tutti i controller e servizi K8s.

Errori comuni nel routing con Ingress controller

Ne abbiamo visti diversi in anni di produzioni:

• Path non normalizzati: se non usi rewrite-target su Nginx, il path originale viene passato al servizio. Potresti finire con richieste a backend/api/orders che non corrispondono alla root del servizio.
• SSL non forzato: se non imposti reindirizzo, il traffico HTTP rimane in chiaro. Sempre inserire force-ssl-redirect (Nginx) o middleware redirectScheme (Traefik).
• Timeout o proxy-buffer insufficienti: per API con corpo grande, imposta proxy-body-size e proxy-read-timeout. Un nostro cliente perdeva upload di documenti perché il limite default era 1 MB.
• Ignorare i healthcheck del controller: Nginx e Traefik hanno readiness probe. Se non configurati, il controller può terminare il traffico anche se il pod è vivo.

Cosa fare adesso

1. Scegli un controller: se vuoi prestazioni pure e team esperto di Nginx → Nginx Ingress Controller. Se preferisci dashboard, middlewares dichiarativi e multi‑orchestratore → Traefik.
2. Deploy via Helm: usa il chart ufficiale (ingress-nginx o traefik/traefik). Configura un solo LoadBalancer con IP statico.
3. Installa cert-manager (se non usi ACME di Traefik) e crea un ClusterIssuer per Let's Encrypt.
4. Aggiungi annotazioni alle tue risorse Ingress per forzare HTTPS, riscrivere path e impostare limiti.
5. Testa con curl: curl -I http://tuo-dominio.com dovrebbe rispondere con 301 al protocollo HTTPS, poi 200 dal backend.
6. Monitora: abilita le metriche (Prometheus) e una dashboard Grafana per vedere latenza, errori 5xx e traffico per host.

Se hai bisogno di una mano con la configurazione o con l'ottimizzazione dei costi del tuo cluster, torniamo alla Pillar principale Kubernetes o vedi come automatizzare il deploy.

Noi di Meteora Web lavoriamo con cluster Kubernetes in produzione dal 2017. Se vuoi un confronto sui costi e le performance della tua architettura, contattaci.