Ingress NGINX: mig Kubernetes el mantenien dues persones

El repositori kubernetes/ingress-nginx està arxivat. Només lectura. L'última versió del controlador, controller-v1.15.1, es va publicar el 19 de març: fa 187 dies. No és un projecte que s'hagi anat apagant per descuit —està retirat expressament, amb data i amb comunicat—, i el que van signar el Steering Committee i el Security Response Committee de Kubernetes per explicar-ho no va ser una fallada de seguretat. Va ser una frase sobre plantilla: «maintained solely by one or two people working in their free time».

Tres dates i dues frases

L'11 de novembre del 2025, el blog de Kubernetes va anunciar la retirada per al març del 2026. El 29 de gener del 2026, els dos comitès van publicar un comunicat conjunt per, en les seves paraules, «reinforce the scale of this change». I al març es va tancar: el repositori va quedar arxivat en només lectura. Això diu la història oficial; ho hem comprovat avui contra l'API de GitHub, que retorna "archived": true, l'últim push datat el 23 de març del 2026 i tres versions del controlador publicades el 19 de març —controller-v1.15.1, controller-v1.14.5 i controller-v1.13.9, amb els seus tres charts de Helm corresponents—, les últimes que existiran. El projecte acumula 19.469 estrelles.

Les dues frases del comunicat que importen són aquestes. La primera acota l'abast: Ingress NGINX és «a piece of critical infrastructure for about half of cloud native environments», i més avall ho xifren citant la font —«According to internal Datadog research, about 50% of cloud native environments currently rely on this tool»—. És recerca interna d'un tercer citada per Kubernetes, no un cens; ho prenem pel que és, un ordre de magnitud. La segona frase no té matís possible: «There will be no more releases for bug fixes, security patches, or any updates of any kind after the project is retired». I el comitè ho rebla sense diplomàcia: «choosing to remain with Ingress NGINX after its retirement leaves you and your users vulnerable to attack».

La dada que calia mirar no era un CVE

Aquí és on aquest cas se separa de la resta. Un fabricant que es retarda amb un pegat és un problema de terminis. Un projecte que es tanca perquè mai va tenir gent és una altra cosa, i el comunicat ho diu amb totes les lletres: hi va haver «years of public warnings that the project was in dire need of contributors and maintainers». Anys. L'avís estava donat i no tenia on aterrar, perquè aquest component no era a la fitxa de ningú: ningú el va comprar, ningú va signar res per ell, i per tant ningú va haver de contestar mai la pregunta que ho predeia sencer —quanta gent hi ha darrere i si cobra per ser-hi—.

Convé dir què NO és això, perquè es presta al titular fàcil. No és un argument contra el programari lliure: la nostra pròpia infraestructura és lliure gairebé de dalt a baix —Proxmox VE, Ceph, Zabbix, WireGuard, Docker Swarm i Kubernetes— i no pensem canviar-la. És un argument a favor de mirar qui manté cada dependència crítica, que és una pregunta neutral respecte a la llicència. El programari de pagament té la seva versió exacta del mateix problema: es diu fi de suport, i l'aparell es queda igual de quiet. Ja ho vam escriure arran d'un altre ecosistema amb el mateix forat de governança: qui manté la teva web és una pregunta amb nom i cognoms, o no és una pregunta. I quan la resposta és «ningú», de vegades directament no hi ha cap pegat a aplicar.

La part més incòmoda del comunicat és la que descriu el silenci: «Existing deployments will continue to work, so unless you proactively check, you may not know you are affected until you are compromised». No cau res. Cap tauler es posa vermell. El mateix comunicat dona l'ordre per sortir de dubtes, i és d'una línia:

kubectl get pods --all-namespaces \
  --selector app.kubernetes.io/name=ingress-nginx

Traduir el YAML és la part fàcil

El 20 de març, tres dies abans d'arxivar el repositori, SIG Network va publicar Ingress2Gateway 1.0, l'eina que tradueix recursos Ingress a Gateway API. El salt d'aquesta versió dona la mesura del problema: abans suportava tres anotacions d'Ingress-NGINX; la 1.0 en suporta més de trenta. Els autors de l'anunci són explícits sobre el que no és: «Ingress2Gateway is a migration assistant, not a one-shot replacement» i «Migration is not a “one-click” affair».

L'eina avisa per escrit del que no pot traduir, i aquests avisos són la llista de decisions que algú haurà de prendre a mà. Tres exemples del mateix anunci: l'anotació configuration-snippet no està suportada; proxy-body-size no té equivalent a Gateway API i es queda sense traduir; i la normalització d'URL no es pot configurar a Gateway API —«Gateway API does not support configuring URL normalization (RFC 3986, Section 6)»—. El que l'eina no et pot avisar és del contrari: del que tradueix de més, perquè l'original feia una cosa que tu no sabies que feia.

Cinc coses que el teu encaminament fa i ningú va triar

Al febrer, Steven Jin (Microsoft) va publicar al blog de Kubernetes un article previ a la migració amb cinc comportaments per defecte d'Ingress-NGINX. Els resumim perquè són, al nostre parer, la part cara d'aquesta mudança:

La nostra lectura, dita com a opinió: el primer i l'últim d'aquesta llista no són detalls d'encaminament, són control d'accés. Si algú va escriure fa tres anys una regla creient que restringia a tres lletres majúscules, fa tres anys que no restringeix res. Aquesta regla no la descobrirà un escàner ni una auditoria de YAML: només apareix quan algú tradueix el fitxer a un altre llenguatge i ha de dir en veu alta què volia dir. Per això aquesta migració no és una traducció, és una lectura.

A favor del destí cal dir això: en normalització d'URL, el mateix article diu que la majoria d'implementacions de Gateway API ja netegen els segments . i .. per defecte, i cita Istio, Envoy Gateway i Kgateway. Així que el risc no és tant perdre la normalització com no saber que la teva aplicació feia anys que s'hi recolzava.

No tradueixis: mesura primer

Canviar el controlador d'entrada d'un clúster és, en la classificació que de debò importa, un canvi de configuració a mà en producció. I allà hi ha literatura: l'estudi d'Oppenheimer, Ganapathi i Patterson presentat a USENIX el 2003 sobre per què fallen els grans serveis d'internet va posar els canvis de configuració dels operadors al capdavant de les causes de caiguda greu, amb el maquinari explicant només entre el 10 i el 25 %. Vint-i-tres anys després continuem veient el mateix a les guàrdies. La diferència entre una fallada i una avaria no la posa el component: la posa el procediment amb què el toques.

Així ho plantegem nosaltres. Primer, l'inventari real no és al YAML sinó al log d'accés del mateix ingress: hosts, rutes i codis de resposta d'un parell de setmanes, que és l'única llista del que de debò fa servir algú. Segon, es tradueix i es llegeix cada avís, perquè un «no suportat» és una decisió de producte disfressada d'advertiment. Tercer, el nou controlador s'aixeca en paral·lel i es compara comportament amb trànsit real abans de tocar el DNS: mateixes rutes, mateixos codis, mateixos redirects. I quart, es canvia amb tornada enrere preparada i assajada, no «documentada». És la mateixa disciplina de desplegaments reproduïbles i reversibles que apliquem a la resta, i que ja vam explicar quan vam escriure que «latest» no és una versió.

El calendari que ningú va pressupostar

Això no s'acaba amb l'ingress, i aquest és el punt que se li escapa a molta direcció quan aprova un projecte amb Kubernetes. La política de suport del projecte és pública i està escrita a la seva pàgina de versions: «the Kubernetes Community will support active patch release series for a period of roughly fourteen (14) months» —dotze mesos de suport estàndard més dos de mode manteniment només per a fallades crítiques—. Amb tres versions menors l'any, el calendari vigent avui és aquest:

Llegit del dret: si avui ets a 1.34, tens fins al 27 d'octubre. I quan arribis a 1.37 tornaràs a tenir una altra data. El cost de Kubernetes no és el clúster, és el calendari: una actualització major cada pocs mesos, per sempre, més el calendari propi de cada peça de l'ecosistema del voltant —i aquest segon calendari no el signa ningú—. Ingress NGINX és just això: una data que no era a cap full de ruta i que ha aparegut igualment.

I ara el que ens va en contra dir, perquè oferim Kubernetes gestionat: no tothom necessita Kubernetes. Operem clústers de Kubernetes i també de Docker Swarm, i triem segons el cas, no segons el que quedi millor en una proposta. Si el teu producte són quatre serveis i una base de dades, amb un equip que no té ningú dedicat a plataforma, el calendari de dalt se l'empassarà algú que hauria d'estar escrivint producte. Aquesta conversa és més barata tenir-la abans que després.

Què faríem aquesta setmana

1. Comprovar si et toca, amb l'ordre del comunicat i amb kubectl get ingressclass. En clústers gestionats per tercers, preguntar també quin controlador va posar el proveïdor: això sol estar instal·lat per un chart que ningú recorda haver triat.
2. Mesurar la mida real de la migració, que no és el nombre d'Ingress sinó el d'anotacions diferents que fas servir. Aquesta línia ho diu en deu segons:

kubectl get ingress -A -o json \
  | jq -r '.items[].metadata.annotations // {} | keys[]' \
  | grep '^nginx.ingress.kubernetes.io/' \
  | sort | uniq -c | sort -rn

3. Treure del log d'accés la llista real d'host + ruta + codi dels últims catorze dies. Aquesta llista és el criteri d'acceptació de la migració; sense ella, «funciona» vol dir «he entrat a la portada i carregava».
4. Traduir amb Ingress2Gateway i llegir els avisos un a un. Cada «unsupported» és una funcionalitat que avui tens i demà no, i algú ha de decidir si això importa. No ho decideix l'eina.
5. I la que no és tècnica: afegir a la fitxa de cada dependència crítica una línia amb quanta gent la manté i si algú cobra per fer-ho. És una pregunta de dos minuts que en aquest cas feia anys que estava contestada en públic —el mateix comunicat parla de «years of public warnings»— i que hauria donat marge en comptes de dos mesos.

El que ens deixa aquest cas: durant anys, la pregunta de governança que tothom feia sobre una dependència era «té CVE oberts?». Resulta que la que predeia el tancament de la porta d'entrada de mig ecosistema no sortia en cap escàner, la contestaven els mateixos mantenidors en veu alta, i era de plantilla. Estava publicada. Ningú la va llegir perquè aquest component no era de ningú.

Nota de fonts

Tot consultat el 22 de setembre del 2026. Un: el comunicat conjunt del Kubernetes Steering Committee i el Security Response Committee, publicat al blog de Kubernetes el 29 de gener del 2026, d'on surten les cites literals que l'obren: l'abast de «about half of cloud native environments», l'atribució del 50 % a recerca interna de Datadog, la frase sobre «one or two people working in their free time», la que diu que no hi haurà més versions ni pegats, l'advertiment que quedar-s'hi exposa a atac, la del silenci fins al compromís i l'ordre de comprovació. Dos: l'anunci de retirada de l'11 de novembre del 2025, també al blog de Kubernetes, que fixa el març del 2026 i recomana migrar a Gateway API o a un altre controlador. Tres: l'API pública de GitHub per a kubernetes/ingress-nginx, consultada avui: camp archived a cert, pushed_at del 23 de març del 2026, les tres etiquetes de versió publicades el 19 de març del 2026 i el recompte d'estrelles. Els 187 dies són nostres, restant dates de calendari entre el 19 de març i avui. Quatre: «Announcing Ingress2Gateway 1.0», blog de Kubernetes del 20 de març del 2026 (Beka Modebadze, Google, i Steven Jin, Microsoft): el salt de tres a més de trenta anotacions, les dues frases sobre que no és un reemplaçament d'un clic i els avisos sobre configuration-snippet, proxy-body-size i la normalització d'URL. Cinc: «Before You Migrate: Five Surprising Ingress-NGINX Behaviors You Need to Know», blog de Kubernetes del 27 de febrer del 2026 (Steven Jin, Microsoft): els cinc comportaments de la taula i la nota que Istio, Envoy Gateway i Kgateway normalitzen per defecte. Sis: la pàgina de versions de pegat de kubernetes.io, d'on surt la cita dels catorze mesos de suport —dotze d'estàndard més dos de manteniment— i les dates d'1.34 a 1.37. Set: Oppenheimer, Ganapathi i Patterson, «Why Do Internet Services Fail, and What Can Be Done About It?», USENIX 2003, per a la causa principal de caigudes greus. El que no afirmem: no hem auditat el codi d'Ingress-NGINX ni reproduït els cinc comportaments en un clúster propi —els recollim de la font citada—; no tenim una xifra pròpia de quants clústers el continuen fent servir; no afirmem que existeixi avui cap vulnerabilitat sense pegat, només que si n'apareix no hi haurà pegat; i no recomanem aquí cap implementació concreta de Gateway API perquè l'elecció depèn de què més corri en aquell clúster. Opinió nostra: que la pregunta útil sobre una dependència és de plantilla i no de CVE, que aquesta migració és una lectura de l'encaminament i no una traducció, que els punts un i cinc de la taula són control d'accés, el mètode de mesurar abans de traduir, i que hi ha casos en què Kubernetes no compensa.

Imatge de portada: fotografia de domini públic d'una bateria de torniquets d'accés, retallada per nosaltres. Els textos i la marca els afegim nosaltres a sobre.