Che cos'è un Ingress e come instrada il traffico esterno verso i Service?

Question

IT Interview Practice · Accepted Answer

Un **Ingress** è un oggetto Kubernetes che definisce **regole di routing HTTP/HTTPS** — mappando hostname e path URL verso i **Service** di backend. Viene realizzato da un **Ingress Controller** (nginx, Traefik, gateway cloud) e ti offre un unico punto di ingresso, la terminazione TLS e il routing per host/path invece di un LoadBalancer per ogni service.

## Il problema che l'Ingress risolve

```text
Exposing many services with type: LoadBalancer means MANY cloud LBs (and public IPs)
— expensive, and no shared hostname/path routing or TLS.
Ingress gives ONE entry point that routes by host & path to internal ClusterIP Services.
```

## Come si incastra il tutto

```text
      Internet
         │
   ┌─────┴──────────────┐
   │ Ingress Controller │  (a Pod, e.g. nginx; usually behind ONE LoadBalancer)
   │  reads Ingress rules│
   └─────┬──────────────┘
         │ routes by host / path
   ┌─────┼───────────────┬───────────────┐
   ▼                     ▼               ▼
 Service: web        Service: api    Service: admin  (all ClusterIP)
   │                     │               │
 Pods                  Pods            Pods

Ingress (rules)  ≠  Ingress Controller (the running proxy that enforces them)
```

## Un manifest di Ingress

```yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  tls:
    - hosts: [shop.example.com]
      secretName: shop-tls        # TLS cert/key stored in a Secret
  rules:
    - host: shop.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api
                port: { number: 80 }
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web
                port: { number: 80 }
```

```text
shop.example.com/api/... → Service "api" → api Pods
shop.example.com/...     → Service "web" → web Pods
TLS is terminated at the controller using the cert in the "shop-tls" Secret.
```

## Punti chiave

```text
• You MUST run an Ingress Controller — the Ingress object alone does nothing.
• ingressClassName selects which controller handles the rules.
• Ingress is HTTP/HTTPS (L7) only. For raw TCP/UDP use a Service or Gateway API.
• The newer Gateway API is the evolving successor with richer, role-oriented routing.
```

```bash
kubectl get ingress                  # list rules, hosts, addresses
kubectl describe ingress app-ingress # see backends & events
```

## Perché è importante

L'Ingress è il modo standard per esporre applicazioni HTTP/HTTPS al mondo esterno su Kubernetes, quindi capirlo è una conoscenza di networking essenziale per gli ingegneri di livello middle. Il problema che risolve è concreto e comune: esporre molti service tramite `type: LoadBalancer` significa effettuare il provisioning di un load balancer cloud e di un IP pubblico separati per ogni service — costoso e privo di routing per hostname condiviso o di TLS — mentre un **Ingress** ti dà un unico punto di ingresso che instrada per **host e path** verso Service ClusterIP interni e termina il **TLS** in modo centralizzato. La distinzione che manda in confusione è tra l'**oggetto Ingress** (le regole di routing dichiarative) e l'**Ingress Controller** (il proxy effettivamente in esecuzione — nginx, Traefik, un gateway cloud — che osserva quelle regole e le applica); le regole non fanno nulla senza un controller installato, e `ingressClassName` seleziona quale controller le gestisce. Capire che l'Ingress opera a **L7 (solo HTTP/HTTPS)** — quindi il TCP/UDP grezzo richiede un Service o la più recente Gateway API — e che la **Gateway API** è il successore in evoluzione, più espressivo, riflette una conoscenza attuale e reale. Poiché quasi ogni applicazione rivolta all'utente su Kubernetes ha bisogno di routing per host/path e di TLS da un unico punto di ingresso, e poiché la distinzione oggetto-vs-controller è una frequente fonte di confusione sia nei colloqui sia nella pratica, una solida padronanza dell'Ingress è fondamentale per esporre e operare workload web su un cluster.

Il problema che l'Ingress risolve

Come si incastra il tutto

Un manifest di Ingress

Punti chiave

Perché è importante

Domande correlate