NGINX Ingress Controller 5.7.0: versione HTTP verso i backend configurabile per servizio

Da NGINX Ingress Controller 5.7.0 si può decidere con quale versione HTTP il controller parla con i pod backend, invece di dipendere sempre da HTTP/1.1 di default. Per chi gestisce cluster Kubernetes con backend misti — alcuni che accettano già HTTP/2 in chiaro (h2c), altri ancora fermi a HTTP/1.0 — la differenza si traduce in meno 502 Bad Gateway e meno configurazioni custom scritte a mano per aggirare il limite.

Tre modi per impostarla

Il controller offre tre leve, in ordine di precedenza decrescente:

1. Annotazione su Ingress o campo su VirtualServer: nginx.org/proxy-http-version: "1.0", "1.1" o "2" sull'Ingress; campo nativo proxy-http-version sotto upstreams nel VirtualServer.
2. appProtocol del Service: se la porta del Service ha appProtocol: kubernetes.io/h2c, il controller genera automaticamente proxy_http_version 2; senza bisogno di annotazioni.
3. Default: se non è impostato nulla, resta HTTP/1.1.

L'annotazione sull'Ingress vince sempre su quanto dichiarato dal Service, utile per forzare temporaneamente HTTP/1.1 in debug senza toccare il manifest del Service. Negli Ingress mergeable (master/minion), un'annotazione sul master viene ereditata dai minion che non ne impostano una propria.

Limiti da tenere a mente

Il WebSocket richiede HTTP/1.1 per il meccanismo di Upgrade: se un Service elencato in nginx.org/websocket-services risolve a HTTP/2 o HTTP/1.0 (anche per inferenza da appProtocol), il controller emette un evento di warning visibile con kubectl describe ingress. I backend gRPC non sono toccati: vengono sempre proxati con grpc_pass in HTTP/2, e l'annotazione viene ignorata con relativo warning. Cambiano anche gli header: su HTTP/2 il controller omette Connection e Upgrade (vietati da RFC 9113 §8.2.2), su HTTP/1.0 invia Connection: close.

Il contesto della release

La funzione fa parte di NGINX Ingress Controller 5.7.0, che sul GitHub ufficiale del progetto risulta essere la release stabile più recente. La stessa versione, secondo il blog di rilascio ufficiale, include più di 30 correzioni di bug e miglioramenti di stabilità e corregge due vulnerabilità di bypass dell'autenticazione esterna, CVE-2026-94197 e CVE-2026-104939, un dettaglio di sicurezza che vale la pena conoscere per chi sta pianificando l'aggiornamento. Va ricordato che questo progetto, sviluppato da F5/NGINX, è distinto dal controller comunitario ingress-nginx, che ha annunciato il proprio ritiro a marzo 2026 e non riceverà più aggiornamenti o patch di sicurezza: chi usa ancora quest'ultimo deve valutare la migrazione.

Per i dettagli di configurazione e gli esempi completi, la documentazione ufficiale resta il riferimento per annotazione e campo VirtualServer.