Planteamiento y alcance
La migración debe preservar los códigos de estado, las rutas, los encabezados y la selección de backends observados externamente mientras se pasa de recursos Ingress y anotaciones específicas del controlador a recursos de Gateway API. La habilidad principal es la ingeniería de compatibilidad en el límite de un proxy, por lo que esta pregunta pertenece a backend. El blog de Kubernetes documenta varios comportamientos de Ingress-NGINX que son fáciles de pasar por alto, incluidos los efectos de expresiones regulares a nivel de todo el host, las redirecciones implícitas y la normalización.
Qué evalúan los entrevistadores
Buscan un inventario del comportamiento real del tráfico en lugar de un mero ejercicio de traducción de YAML. Los candidatos sólidos separan la semántica portable de Gateway API de las expresiones regulares específicas de la implementación, identifican el comportamiento implícito que necesita un filtro explícito y proponen pruebas diferenciales con reversión. También deben discutir la propiedad, las dependencias de certificados y listeners, la observabilidad y un corte por etapas de DNS o de tráfico.
Preguntas para aclarar primero
- ¿Qué versión de Ingress-NGINX, anotaciones, controlador de Gateway API y nivel de conformidad están desplegados?
- ¿Qué hosts utilizan
use-regex,rewrite-target, autenticación, canary o snippets personalizados? - ¿Dependen los clientes de redirecciones 301, mayúsculas/minúsculas en rutas, barras duplicadas o segmentos codificados?
- ¿Puede el nuevo Gateway ejecutarse en paralelo y recibir tráfico reflejado o muestreado?
- ¿Quién es el propietario de los recursos Gateway, HTTPRoute, políticas de backend y TLS?
- ¿Cuál es el disparador de reversión y con qué rapidez puede regresar el tráfico al controlador anterior?
Estructura de respuesta en 30 segundos
“Primero capturaría un inventario de comportamiento a partir de manifiestos, registros de acceso y sondeos de caja negra. Generaría recursos de Gateway API por comportamiento, modelando explícitamente expresiones regulares, reescrituras, redirecciones y TLS en lugar de asumir que las anotaciones se traducen directamente. Luego ejecutaría pruebas diferenciales contra los controladores antiguo y nuevo, tráfico en la sombra o canary, compararía estado, ubicación, backend seleccionado y latencia, y mantendría lista la reversión de DNS o enrutamiento. Solo después de cero diferencias no explicadas migraría cada host.”
Respuesta paso a paso
Paso 1: Inventariar los contratos observados
Analiza cada host y ruta, pero verifícalos con solicitudes. La coincidencia de expresiones regulares de Ingress-NGINX puede no distinguir entre mayúsculas y minúsculas y estar basada en prefijos, y una anotación puede afectar a todas las rutas de un host en múltiples objetos Ingress. Registra redirecciones, rutas normalizadas, encabezados, autenticación, tiempos de espera y elecciones de backend como contratos comprobables.
Paso 2: Clasificar el comportamiento portable y el específico del controlador
Mapea el enrutamiento ordinario de host/ruta a Gateway y HTTPRoute. Trata la coincidencia de expresiones regulares como específica de la implementación y verifica la semántica del controlador seleccionado. Convierte el comportamiento de reescritura y redirección en filtros explícitos de HTTPRoute donde sea compatible. Las anotaciones o snippets no compatibles se convierten en bloqueadores de migración con un propietario y un diseño de reemplazo.
Paso 3: Construir una matriz de pruebas diferenciales
Para cada contrato, prueba rutas normales y adversarias: variantes de mayúsculas y minúsculas, barra final, segmentos . y .., barras duplicadas, caracteres codificados, rutas faltantes y fallas de backend. Compara el estado, Location, la ruta recibida por el backend, los encabezados, el servicio seleccionado y el cuerpo del error. Utiliza los mismos fixtures y encabezados de solicitud para ambos controladores.
Paso 4: Demostrar la preparación del controlador y las políticas
Verifica las condiciones de estado de Gateway y HTTPRoute, la asociación de listeners, la preparación de certificados, la política de referencias entre namespaces y el soporte de implementación para cada filtro. Un recurso aceptado por la API no es prueba de que el plano de datos implemente cada característica solicitada.
Paso 5: Canary y reversión
Ejecuta un Gateway paralelo con un host o una porción pequeña de tráfico. Refleja solicitudes idempotentes seguras cuando sea posible; de lo contrario, reproduce fixtures sanitizados. Cancela ante diferencias de enrutamiento no explicadas, cambios en 4xx/5xx, desviaciones en redirecciones o regresiones de latencia. Mantén el controlador antiguo y los pesos de DNS o tráfico sin cambios hasta que se cierre la ventana de observación.
Respuesta modelo
“Trataría el comportamiento actual de Ingress-NGINX como un contrato externo. Después de inventariar manifiestos, anotaciones, registros y sondeos, modelaría cada contrato explícitamente en recursos Gateway y HTTPRoute. Las expresiones regulares, reescrituras, redirecciones de barra final y la normalización de URL necesitan verificación específica del controlador; algunos comportamientos implícitos deben convertirse en filtros explícitos. Ejecutaría una matriz diferencial que cubra el estado, Location, la ruta del backend, los encabezados y la selección de servicios, y luego haría un despliegue canary con pesos de reversión. Las condiciones de estado de Gateway y las declaraciones de conformidad son necesarias pero no suficientes, por lo que conservaría evidencia de caja negra antes de cambiar el DNS.”
Errores comunes
- Traducir YAML uno a uno → las anotaciones pueden acarrear efectos ocultos en todo el host → inventaria el comportamiento en tiempo de ejecución y pruébalo.
- Asumir que
Exactsignifica coincidencia idéntica → el controlador antiguo puede tener efectos secundarios de expresiones regulares o normalización → sondea variantes de mayúsculas/minúsculas, barras y codificación. - Confiar en el estado Accepted del recurso → el soporte en el plano de datos aún puede ser incompleto → verifica las condiciones y las respuestas de caja negra.
- Cortar el DNS primero → la reversión se vuelve lenta y opaca → haz un despliegue canary del tráfico mientras la ruta antigua permanezca disponible.
- Ignorar las rutas visibles para el backend → las reescrituras pueden romper aplicaciones → comprueba la ruta y los encabezados recibidos por el backend.
- Probar solo los caminos felices (happy paths) → las interrupciones se ocultan en redirecciones y URLs mal formadas → incluye fixtures negativos y adversarios.
Preguntas de seguimiento
Pregunta de seguimiento 1: ¿Por qué la migración de expresiones regulares puede cambiar el tráfico?
Ingress-NGINX puede aplicar un comportamiento de expresiones regulares tipo prefijo que no distingue entre mayúsculas y minúsculas en todas las rutas de un host. Las expresiones regulares de Gateway API son específicas de la implementación, mientras que Exact y Prefix no se convierten silenciosamente en expresiones regulares.
Pregunta de seguimiento 2: ¿Cómo se preserva una redirección de barra final?
Modélala explícitamente con un filtro de redirección HTTP y prueba ambas variantes de barra. No asumas que una implementación de Gateway agrega el antiguo 301 automáticamente.
Pregunta de seguimiento 3: ¿Qué es una señal segura de reversión?
Utiliza diferencias no explicadas en el estado, Location, la ruta del backend, la selección de servicios, la tasa de errores o la latencia, evaluadas contra una línea base fija y una ventana de observación acotada.
Pregunta de seguimiento 4: ¿Qué demuestran las herramientas de migración?
Un conversor puede acelerar el inventario y producir recursos candidatos, pero no puede demostrar la semántica específica del controlador, las interacciones ocultas de anotaciones o la compatibilidad de las aplicaciones. Mantén las pruebas diferenciales como la compuerta de lanzamiento (release gate).