La imposibilidad súbita de descargar el Helm chart application-gateway-kubernetes-ingress (AGIC) detuvo los despliegues en numerosos clústeres de producción. A continuación se analiza en detalle la causa raíz, el estado del incidente, las vías de escalado y las acciones para reanudar los despliegues de inmediato.
Descripción del incidente
Durante la madrugada del 28 de julio de 2025 varios equipos de DevOps empezaron a recibir el error 404 Not Found al ejecutar helm repo add o helm install contra el repositorio oficial de AGIC. La avería fue reproducible en todas las regiones de Azure y afectó tanto a entornos de integración continua (CI) como a clústeres en vivo. El alcance fue global porque el chart se aloja en un único almacenamiento CDN que sirve al índice index.yaml, pieza fundamental para la resolución de versiones.
Causa raíz probable
Aunque Microsoft aún no publica un RCA oficial, la evidencia apunta a una combinación de:
- Actualización incompleta del índice Helm: un pipeline automatizado sustituyó el archivo
index.yamlantes de que todos los artefactos de versión estuvieran replicados, generando referencias huérfanas. - Falta de validación de firma: el flujo de trabajo estándar firma el índice Helm con
cosign. La extracción prematura de la firma bloquea la propagación del archivo y provoca que los mirrors descarten la copia «huérfana». - TTL agresivo en caché CDN: el proveedor CDN configuró un TTL de 72 horas para archivos ausentes. Tras el primer fallo, todos los nodos perimetrales devolvieron
404hasta nueva purga.
El resultado fue un corte total del servicio de distribución del chart, sin ruta de conmutación al no existir espejo secundario oficial.
Impacto operacional
Los principales síntomas observados fueron:
- Fallo de nuevas instalaciones de AGIC con
helm install. - Incapacidad para escalar deployments existentes que dependían de
helm upgrade. - Ruptura de pipelines CI/CD que ejecutan comprobaciones sanitarias (
helm dependency update). - Bloqueo en entornos multiclúster que automatizan el roll‑out de revisiones (blue/green, canary).
Escalado y actualizaciones del incidente
La incidencia fue reportada inicialmente en un foro comunitario de Kubernetes Ingress Controllers. La respuesta oficial indicó que el canal carece de ingenieros AGIC dedicados y pidió migrar la consulta al portal Microsoft Q&A. Desde entonces se han registrado los siguientes hitos:
| Fecha y hora UTC | Evento |
|---|---|
| 28‑07‑2025 06:17 | Primer reporte público con helm install fallido. |
| 28‑07‑2025 09:52 | Confirmación de ingenieros externos: reproducible en todas las regiones. |
| 28‑07‑2025 12:31 | Apertura del issue #1644 en GitHub. |
| 28‑07‑2025 16:05 | Respuesta del equipo de soporte: “Trasladar a Microsoft Q&A con etiquetas adecuadas”. |
| 29‑07‑2025 08:20 | Caso de soporte de severidad Crítica abierto desde Azure Portal. |
| 29‑07‑2025 21:40 | Ingeniero de producto confirma investigación interna del pipeline de publicación. |
| 30‑07‑2025 14:10 | Purga manual de CDN en progreso; sin ETA oficial. |
Se recomienda suscribirse al issue #1644 y al caso de Microsoft Q&A para recibir webhooks automáticos con cada comentario oficial.
Solución inmediata para reanudar despliegues
Mientras el repositorio oficial vuelve a estar operativo, hay tres rutas rápidas que permiten retomar la automatización:
- Instalar desde una copia local existente
Si su equipo aún dispone del paquete tgz:helm install ingress-agic ./application-gateway-kubernetes-ingress-X.Y.Z.tgz \ --namespace kube-system --create-namespace - Crear un repositorio Helm interno
git clone https://github.com/Azure/application-gateway-kubernetes-ingress.git cd application-gateway-kubernetes-ingress/charts/ingress-azure helm package . helm repo index . --url https://<su‑dominio>/helm/agic helm repo add agic-internal https://<su‑dominio>/helm/agic helm install ingress-agic agic-internal/ingress-azure --version X.Y.Z - Publicar en un ACR (Azure Container Registry)
az acr helm push --name <acrName> application-gateway-kubernetes-ingress-<X.Y.Z>.tgz helm repo add agic-acr https://<acrName>.azurecr.io/helm/v1/repo helm install ingress-agic agic-acr/application-gateway-kubernetes-ingress --version X.Y.Z
Guía práctica de mitigaciones y buenas prácticas
| Paso | Acción recomendada | Detalle |
|---|---|---|
| Escalar por los canales correctos | • Abrir un ticket de soporte desde Azure Portal con severidad Alta o Crítica. • Publicar la consulta en Microsoft Q&A usando las etiquetas azure-application-gateway, kubernetes-ingress, helm-chart. | Garantiza que un ingeniero del producto reciba la incidencia y pueda proporcionar un ETA oficial. |
| Aplicar mitigaciones temporales | • Si ya tenía una copia local del chart, instálelo fijando la versión. • Clonar el repositorio GitHub y generar un repositorio Helm local. • Utilizar un espejo confiable o un repositorio interno (p. ej. ACR, Artifactory) hasta que el oficial vuelva a estar disponible. | Permite continuar los despliegues sin esperar al restablecimiento del repo original. |
| Supervisar el progreso | • Seguir el issue #1644 en GitHub para conocer actualizaciones. • Activar notificaciones en ese issue y en la rama main del proyecto. | Asegura visibilidad inmediata de cualquier corrección o comentario del equipo de AGIC. |
| Prevenir incidentes similares | • Mantener un cache interno de Helm charts aprobados. • Añadir pruebas automáticas de helm repo update && helm fetch a los pipelines CI/CD.• Documentar un plan de contingencia para la cadena de suministro de artefactos. | Reduce la dependencia de repositorios públicos y proporciona resiliencia operativa. |
Buenas prácticas a largo plazo
Diseñar pipelines idempotentes Incluya la etapa helm dependency build en lugar de helm dependency update para evitar acceder a repos externos durante un despliegue reproducible. Versionar artefactos críticos Guarde cada .tgz validado en un bucket S3, Blob Storage o Artifactory y etiquételo con la huella SHA‑256. Firmar y verificar charts Integre cosign sign en el flujo de publicación y helm verify en la fase previa a kubectl apply. Implementar canary deployments Despliegue versiones menores de AGIC en un subconjunto controlado de clústeres antes del roll‑out global.
Preguntas frecuentes
¿Puedo cambiar a NGINX Ingress temporalmente?
Sí, pero evalúe el impacto en la configuración de tráfico y reglas de WAF. El cambio exige migrar anotaciones específicas de Application Gateway.
¿Qué ocurre con las actualizaciones automáticas de Helm en GitHub Actions?
Si el workflow usa dependabot o renovate, se registrarán fallos hasta que el índice Helm vuelva a ser accesible. Deshabilite temporalmente el job o aplique un pin de versión.
¿La interrupción afecta a los controladores ya desplegados?
No. Los pods existentes seguirán operando porque Helm se usa solo en la fase de instalación/actualización. El plano de datos de Application Gateway permanece intacto.
Conclusión
La caída del repositorio público de AGIC demuestra la importancia de contar con una cadena de suministro de artefactos resiliente. Al aplicar las mitigaciones descritas —repo interno, caché, firma y verificación— los equipos pueden reanudar sus despliegues mientras Microsoft restaura el servicio. Paralelamente, abrir un caso de soporte y seguir los canales oficiales garantiza recibir una línea de tiempo clara de reparación y evita la repetición del problema.