GitOps

Si gestionas infraestructura Kubernetes en producción, el anuncio de la depreciación de Ingress-NGINX no fue una sorpresa, sino un recordatorio crudo de la realidad del ecosistema: la obsolescencia es una constante. Lo que hoy es un componente crítico, mañana puede ser un legacy que amenaza la estabilidad y seguridad de tu plataforma.

La depreciación de Ingress-NGINX, un controlador que ha sido la columna vertebral del tráfico entrante para miles de clusters, no es un evento aislado. Es un patrón que se repetirá con otros componentes a medida que Kubernetes evoluciona. La pregunta crítica para los equipos de plataforma no es «¿cómo migramos este componente?», sino «¿cómo construimos un marco de trabajo reutilizable para gestionar estas migraciones de forma sistemática, segura y con mínima interrupción?».

En este artículo, no solo analizaremos las lecciones específicas de Ingress-NGINX, sino que las abstraeremos en un framework de migración para Kubernetes que tu equipo puede aplicar a cualquier cambio mayor: desde la transición a Gateway API, hasta la migración de CNIs, cambios de versión de control-plane, o la adopción de nuevos CRDs. Este framework está diseñado para ingenieros senior, arquitectos y SREs que necesitan un enfoque práctico y metódico para el cambio en entornos empresariales.

Por qué necesitas un framework, no solo un plan ad-hoc

Migrar un componente como el controlador de ingress en un cluster de producción es una operación de alto riesgo. Impacta el tráfico de red, la seguridad (TLS), la observabilidad y, en última instancia, la disponibilidad de tus aplicaciones. Un enfoque ad-hoc, basado en scripts sueltos y manuales, introduce puntos de fallo, hace imposible la validación consistente y dificulta el rollback en caso de problemas.

Un framework proporciona:

• Consistencia: El mismo proceso para diferentes migraciones.
• Visibilidad: Estado claro en cada fase.
• Automatización: Reducción de errores humanos.
• Seguridad: Puntos de validación y compuertas (gates) definidos.
• Reversibilidad: Un camino claro para deshacer los cambios.

La documentación oficial de Kubernetes sobre gestión de despliegues enfatiza estrategias como el despliegue gradual y el rollback, principios que son la base de nuestro framework.

Fase 1: Evaluación y Análisis de Impacto

Antes de escribir una línea de código o un manifiesto YAML, debes entender completamente el alcance. Esta fase responde a la pregunta: «¿Qué estamos tocando y qué puede romperse?».

1.1. Inventario de Recursos y Dependencias

Para una migración de ingress, no solo son los objetos Ingress. Debes catalogar:

• Recursos Directos: Todos los objetos Ingress en todos los namespaces, con sus anotaciones específicas (nginx.ingress.kubernetes.io/*).
• Configuración Global: ConfigMaps que contienen la configuración del controlador (e.g., nginx-configuration).
• Dependencias de Infraestructura: Services de tipo LoadBalancer, certificados TLS (manejados por cert-manager o similares), políticas de red (NetworkPolicies).
• Integraciones de Observabilidad: Dashboards de Grafana, alertas de Prometheus, logs estructurados que dependen de etiquetas específicas de NGINX.

Un comando inicial como kubectl get ingress -A es el punto de partida, pero se necesita un análisis más profundo para capturar anotaciones personalizadas y configuraciones complejas.

1.2. Análisis de Brechas (Gap Analysis)

Compara las capacidades del componente antiguo con las del nuevo. En el caso de migrar de Ingress-NGINX a Gateway API (usando, por ejemplo, un controlador como Gateway API con Envoy o NGINX Kubernetes Gateway), identifica:

• Funcionalidades equivalentes: ¿El nuevo componente soporta rewrite rules, auth annotations, canary deployments de la misma forma?
• Paradigmas diferentes: Gateway API separa los roles (Infraestructura vs. Aplicación) mediante GatewayClass, Gateway, y HTTPRoute. Esto es un cambio arquitectónico, no solo una sustitución.
• Características no soportadas: Algunas anotaciones muy específicas de NGINX pueden no tener un equivalente directo y requerir una solución alternativa.

Este análisis te permitirá categorizar los recursos: aquellos con una migración trivial, aquellos que requieren reconfiguración, y aquellos que pueden ser un bloqueador (show-stopper).

Fase 2: Diseño y Estrategia de Despliegue

Con el alcance definido, diseñamos el cómo. La clave aquí es la coexistencia pacífica y el despliegue incremental.

2.1. Patrón de Despliegue Dual (Dual-Homing)

El patrón más seguro para migrar tráfico de red es ejecutar ambos controladores (el antiguo y el nuevo) en paralelo. Esto permite:

• Migración por servicio/dominio: Enrutar el tráfico de un host específico (app1.example.com) al nuevo controlador, mientras el resto sigue por el antiguo.
• Pruebas en producción con tráfico real controlado: Usar un subconjunto de usuarios (por ejemplo, mediante un header HTTP) para enviar tráfico al nuevo ingress.
• Rollback instantáneo: Basta con reconfigurar el DNS o el balanceador de capa 4 para volver al controlador antiguo.

Como señala el framework de Google para esta migración, esta fase requiere una cuidadosa planificación de la IP del balanceador de carga y la gestión de DNS.

2.2. Automatización de la Conversión de Manifiestos

Convertir manualmente cientos de objetos Ingress es inviable y propenso a errores. Debes crear o utilizar herramientas de conversión. El objetivo no es una conversión 1:1 perfecta (el análisis de brechas ya habrá identificado diferencias), sino generar un artefacto base que luego será revisado y ajustado.

Un script simple en Python o Go puede leer los objetos Ingress existentes y generar los correspondientes HTTPRoute y referencias a Gateway. Este es un ejemplo conceptual de la lógica:

# Pseudocódigo para ilustrar el flujo de conversión
ingress_resources = kubectl_get_all_ingresses()
for ingress in ingress_resources:
    http_route = HTTPRoute()
    http_route.metadata.name = ingress.metadata.name
    http_route.metadata.namespace = ingress.metadata.namespace
    
    for rule in ingress.spec.rules:
        host_rule = HTTPRouteRule()
        host_rule.hostnames = [rule.host]
        # Mapear paths y backends...
        # **Aquí se aplicarían las reglas del Gap Analysis**
        http_route.spec.rules.append(host_rule)
    
    # Gestionar TLS: mapeo a Gateway, no a Secret en HTTPRoute
    if ingress.spec.tls:
        # Nota: En Gateway API, TLS se configura en el recurso Gateway.
        # Esto requiere una estrategia de agrupación por host/Secret.
        pass

La salida de esta automatización debe ser revisada por un ingeniero para los casos complejos antes de aplicarse al cluster.

Fase 3: Implementación y Validación Gradual

Esta es la fase de ejecución, donde el framework impone compuertas (gates) de validación entre cada paso.

3.1. Fase 1: Despliegue del Nuevo Controlador en Modo Pasivo

Instala el nuevo controlador (ej: un operator de Gateway API) pero no lo expongas al tráfico de producción. Configúralo para que escuche en un Service interno o en una IP de LoadBalancer diferente. Valida:

• Los pods del controlador están Ready.
• Los CRDs necesarios están instalados.
• Puedes crear recursos de prueba (HTTPRoute) y el controlador los sincroniza (revisa los logs o el estado del recurso).

3.2. Fase 2: Migración de un Servicio No Crítico (Piloto)

Selecciona un servicio de bajo riesgo, preferiblemente interno o con poco tráfico. Aplica los manifiestos convertidos y configura el DNS o el balanceador de capa 4 para enviar el tráfico de ese host específico al nuevo controlador.

Validaciones post-migración (Checklist):

• Conectividad básica: ¿Responde el servicio con un código 2xx/3xx?
• Funcionalidad específica: ¿Funcionan las reglas de rewrite, redirecciones, autenticación?
• TLS: ¿Los certificados se presentan correctamente? ¿La cadena de confianza es válida?
• Observabilidad: ¿Aparecen logs en el nuevo formato? ¿Las métricas (peticiones/segundo, latencia) se exponen a Prometheus?
• Prueba de rollback: Vuelve a enrutar el tráfico al controlador antiguo y confirma que todo sigue funcionando.

3.3. Fase 3: Expansión y Automatización del Pipeline

Tras el éxito del piloto, migra grupos de servicios siguiendo un criterio (por namespace, por equipo dueño, por criticidad). Idealmente, integra este proceso en tu pipeline de GitOps:

1. El ingeniero modifica la ruta (Kustomize overlay, Helm value) para apuntar al nuevo Gateway.
2. El cambio se fusiona (merge) y es aplicado por el operador GitOps (ArgoCD, Flux).
3. Un job de validación post-despliegue ejecuta smoke tests contra el servicio.
4. Una alerta monitoriza el error rate del servicio migrado; si supera un umbral, puede disparar un rollback automático.

Fase 4: Rollback y Lecciones Aprendidas

Un framework de migración robusto trata el rollback no como un fracaso, sino como una característica esencial del proceso.

4.1. Estrategias de Rollback Granular

Debes poder revertir a diferentes niveles:

• Rollback por servicio: Reconfigurar el enrutamiento de un host específico al controlador antiguo.
• Rollback masivo: Tener un script o playbook listo para reenrutar todo el tráfico al controlador antiguo en minutos. Esto implica mantener el controlador antiguo operativo y con capacidad suficiente hasta el final de la ventana de migración.
• Rollback de configuración: Si el problema está en un manifiesto HTTPRoute erróneo, debes poder revertir el commit en Git y dejar que GitOps sincronice el estado anterior.

4.2. Documentación y Conclusión

Una vez completada la migración (o incluso después de cada fase), documenta:

• Problemas encontrados y su solución: Este es el conocimiento tribal más valioso.
• Métricas de éxito: Tiempo total, tasa de error durante la migración, recursos consumidos.
• Mejoras para el framework: ¿Faltó un punto de validación? ¿Podría automatizarse más un paso?

Esta documentación no es un reporte para la gerencia; es la entrada para refinar el framework y prepararlo para la próxima migración inevitable.

Conclusión: Más allá de Ingress-NGINX

La depreciación de Ingress-NGINX es un caso de estudio perfecto, pero el framework descrito aquí es aplicable a cualquier cambio disruptivo en tu plataforma Kubernetes: la migración a un nuevo CNI, el cambio de una versión mayor del control-plane con APIs obsoletas, la adopción de un nuevo modelo de service mesh, o la consolidación de múltiples clusters.

La constante en Kubernetes es el cambio. La ventaja competitiva de un equipo de plataforma no reside en conocer el componente de moda, sino en poseer un proceso sistemático, automatizado y seguro para adoptar, operar y eventualmente retirar cualquier componente. Invertir en construir y refinar este framework de migración es invertir en la resiliencia y velocidad a largo plazo de tu plataforma. La próxima depreciación importante no será una crisis, sino solo otra ejecución en el playbook de tu equipo.