Il progetto Kubernetes ha annunciato che la manutenzione di ingress-nginx sarebbe terminata a marzo 2026, senza altre correzioni né per i difetti né per le vulnerabilità. La raccomandazione è passare a Gateway API. Fonte: annuncio del ritiro.
Checklist
- Inventario. Elenca tutte le risorse
Ingress, le classi e le annotazioninginx.ingress.kubernetes.io/*in uso. Le annotazioni sono il punto critico: ognuna va tradotta. - Scelta dell’implementazione. Gateway API è una specifica; serve un controller che la realizzi (per esempio Cilium, Envoy Gateway, Istio, NGINX Gateway Fabric o quello del tuo cloud). Valuta supporto, sicurezza e costi di gestione.
- Conversione di prova. Lo strumento ingress2gateway, citato nell’annuncio del ritiro, genera una bozza di
GatewayeHTTPRoute. Non è automatica al 100%: rivedi ogni regola. - Parità funzionale. Verifica riscritture di percorso, TLS, timeout, limiti di dimensione, autenticazione, CORS, rate limit. Quello che non ha un equivalente va risolto con una policy del controller scelto.
- Ambiente di prova. Replica i percorsi critici e lancia test automatici sulle risposte attese.
- Parallelo. Metti il nuovo gateway accanto al vecchio ingress, con un indirizzo diverso, e sposta il traffico poco per volta (peso DNS o bilanciatore a monte).
- Osservabilità. Confronta codici di risposta, latenze e log tra vecchio e nuovo prima di ogni passo.
- Ritorno indietro. Tieni il vecchio ingress attivo finché non hai un periodo stabile di traffico sul nuovo.
- Pulizia. Rimuovi il controller, le annotazioni e le risorse inutilizzate; aggiorna la documentazione.
Errori comuni
- Considerare la conversione automatica come finita.
- Dimenticare i certificati e il rinnovo automatico.
- Cambiare insieme gateway e versione di Kubernetes: due variabili sono troppe.
Se vuoi un piano su misura per il tuo cluster, vedi Kubernetes e piattaforme cloud native.