Entrevista de backend: ¿Cómo migrarías de forma segura los externalIPs de Service en Kubernetes tras su desuso en v1.36?

Pregunta y alcance

Administras un clúster de Kubernetes bare-metal donde los equipos usan Service.spec.externalIPs para enrutar direcciones públicas directamente a los Services. Tras actualizar a v1.36, aparecen advertencias de desuso y los revisores de seguridad se preocupan de que un inquilino pueda reclamar una dirección arbitraria e interceptar tráfico. Diseña una migración: descubre dependencias reales, elige un controlador LoadBalancer o Gateway API por punto de entrada, bloquea nuevos usos y demuestra la reversión.

La documentación de Kubernetes indica que externalIPs no son asignadas ni verificadas en propiedad por Kubernetes. En v1.36 el campo queda en desuso; se espera que las versiones posteriores deshabiliten el comportamiento de kube-proxy y eventualmente lo eliminen. Distingue la ventana de compatibilidad actual del objetivo a largo plazo; el desuso no significa una eliminación inmediata.

Contexto y límites

Enfócate en la conectividad de Service, RBAC, políticas de admisión, el orden de la migración y la observabilidad. Los balanceadores de carga en la nube, los dispositivos de red bare-metal y el DNS son dependencias de la plataforma; define sus contratos, la prueba de propiedad de la dirección, la ventana de doble entrada y la contingencia ante fallas.

Lo que evalúa el entrevistador

• Si distingues el campo de especificación externalIPs de Service de una dirección ExternalIP de Node y de una dirección de LoadBalancer mostrada.
• Si puedes trazar una migración de extremo a extremo a través de auditoría, tráfico, permisos, controladores y DNS.
• Si DenyServiceExternalIPs puede bloquear nuevas escrituras sin eliminar el tráfico empresarial existente.
• Si comparas los límites de propiedad y reversión de los controladores LoadBalancer, controladores tipo MetalLB y Gateway API.
• Si las métricas y la transición escalonada demuestran que no hay agujeros negros de tráfico ni secuestro de IP.

Respuesta en 30 segundos

“Haría un inventario de especificaciones de Service, registros de auditoría, DNS, enrutamiento de nodos y tráfico real, mapeando cada externalIP a un inquilino, puerto y backend. Durante la migración habilitaría DenyServiceExternalIPs para bloquear únicamente valores nuevos, dejando los objetos existentes disponibles para su eliminación. Para cada punto de entrada elegiría un controlador LoadBalancer controlado por el administrador o Gateway API, validaría verificaciones de estado, direcciones de origen y drenaje de conexiones mediante una ruta paralela, y luego cambiaría el DNS o el upstream. Después de que el tráfico antiguo llegue a cero, eliminaría las externalIPs, conservaría una instantánea de reversión y condicionaría el despliegue con métricas de auditoría, 5xx, fallas de conexión y conflictos de direcciones.”

Solución paso a paso

1. Construir el inventario. Lista cada Service que use externalIPs, sus direcciones, puertos, namespace, propietario, TTL de DNS, protocolo, EndpointSlices, política de tráfico externo y tráfico reciente. Separa el campo de las entradas .status.addresses de Node denominadas ExternalIP.

1. Modelar el riesgo de seguridad. Un usuario escribe externalIPs en la especificación de Service mientras Kubernetes no asigna la dirección ni garantiza su unicidad. Un inquilino con pocos privilegios puede reclamar la dirección de otro inquilino e interceptar tráfico. Audita creaciones, actualizaciones, eliminaciones y reglas de kube-proxy, correlacionando anomalías por dirección e inquilino.

1. Bloquear nuevos usos primero. Habilita DenyServiceExternalIPs. Rechaza nuevos Services que usen el campo y nuevos valores agregados a Services existentes, mientras que la eliminación de valores existentes sigue siendo posible. Prueba en modo de auditoría o en un clúster de bajo riesgo antes de la aplicación estricta; migra los objetos existentes por separado.

1. Elegir el reemplazo. En entornos de nube, prefiere un type: LoadBalancer controlado por el administrador. En bare-metal, usa un controlador con un grupo de direcciones y verificación de conflictos. Cuando la separación de roles o el enrutamiento compartido sean importantes, usa Gateway API: la plataforma es propietaria del Gateway y las aplicaciones administran objetos HTTPRoute restringidos.

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
spec:
  gatewayClassName: platform-public
  addresses:
  - type: IPAddress
    value: 192.0.2.4

Esto ilustra únicamente el direccionamiento propiedad del administrador. Verifica la GatewayClass, las capacidades del controlador, los certificados y el grupo de IP para el despliegue antes de aplicarlo.

1. Ejecutar validación en paralelo. Coloca el nuevo punto de entrada detrás de un nombre de host separado o un DNS con TTL bajo y compara el éxito de conexión, TLS, dirección de origen, conexiones de larga duración, verificaciones de estado y convergencia de EndpointSlice. Si reutilizas una IP, registra la propiedad en el nuevo controlador antes de cambiar los upstreams para que dos implementaciones nunca la anuncien al mismo tiempo.

1. Drenar y eliminar. Observa que no haya nuevas conexiones en el punto de entrada anterior y espera el tiempo de vida máximo de las conexiones. Elimina las externalIPs mientras conservas evidencia de auditoría y una instantánea de reversión. El orden debe preservar al menos una ruta verificable entre DNS, balanceador de carga, Service y backend.

1. Planificar versiones y reversión. v1.36 emite advertencias de desuso; el cronograma publicado prevé que el comportamiento de kube-proxy se deshabilite no antes de v1.40 y la eliminación completa no antes de v1.43. La reversión restaura únicamente un punto de entrada antiguo cuya propiedad haya sido validada; nunca vuelve a permitir escrituras arbitrarias de los inquilinos. Si el reemplazo falla, revierte temporalmente la configuración de DNS o del controlador sin dejar de bloquear nuevos riesgos.

Respuesta modelo

Trataría cada externalIP como un activo de migración, no como un campo que deba reemplazarse a ciegas. El inventario de API, la auditoría, el DNS, las reglas de nodo y los registros de tráfico establecen la dirección, inquilino, puerto, tiempo de vida de conexión y propiedad. El campo es una especificación de Service editable por el usuario y Kubernetes no lo asigna ni comprueba conflictos, lo que crea el tipo de riesgo de intercepción de CVE-2020-8554.

Durante la migración habilitaría DenyServiceExternalIPs para rechazar adiciones preservando la eliminación de valores existentes. El reemplazo depende del punto de entrada: un LoadBalancer en la nube, un controlador bare-metal con un grupo de direcciones administrado, o Gateway API con Gateways propiedad de la plataforma y rutas restringidas propiedad de la aplicación. Un nombre de host paralelo o una transición con TTL bajo compara el comportamiento de conexión, TLS, dirección de origen y verificaciones de estado antes de drenar conexiones antiguas y eliminar el campo.

El plan registra las advertencias de v1.36, el cambio de comportamiento de kube-proxy más temprano previsto para v1.40 y la eliminación completa más temprana en v1.43. La reversión restaura únicamente un punto de entrada validado propiedad del administrador. Haría seguimiento de conflictos de direcciones, 5xx, fallas de conexión, retraso de propagación de DNS y Services restantes.

Errores comunes

• Error: Tratar el desuso como eliminación inmediata → Por qué falla: se interpreta mal la ventana de compatibilidad y provoca tiempo de inactividad no planificado → Solución: planifica advertencias, inhabilitación del comportamiento y eliminación como hitos separados.
• Error: Reemplazar externalIPs directamente con loadBalancerIP → Por qué falla: los grupos de direcciones y comprobaciones de conflictos aún pueden eludirse → Solución: permite que un controlador gestionado por el administrador asigne y publique el estado.
• Error: Eliminar todos los campos antiguos cuando comienza la aplicación de admisión → Por qué falla: no hay evidencia de tráfico ni de drenaje de conexiones → Solución: bloquea adiciones, prueba el reemplazo gradualmente, drena y luego elimina activo por activo.
• Error: Comprobar solo Services y no DNS, reglas de nodos y tráfico → Por qué falla: quedan puntos de entrada ocultos o agujeros negros → Solución: mantén un inventario de migración de extremo a extremo y una ventana de observación.
• Error: Permitir que los inquilinos sean propietarios de las direcciones del Gateway → Por qué falla: el reemplazo recrea la falla de permisos → Solución: Gateways propiedad de la plataforma y rutas de aplicación restringidas.

Preguntas de seguimiento y respuestas

¿Afecta DenyServiceExternalIPs a los Services existentes?

Rechaza nuevos Services que usen el campo y nuevos valores agregados a Services existentes; eliminar valores existentes sigue siendo posible. Verifica el comportamiento en la versión de destino y observa los eventos de rechazo. Es una protección, no una herramienta de migración automática.

¿Por qué no asignar manualmente una IP de LoadBalancer en bare-metal?

La asignación manual aún carece de grupos de direcciones, detección de conflictos, estado de salud y auditoría. Un controlador con un grupo propiedad del administrador convierte la asignación, liberación y unicidad en una responsabilidad de la plataforma; las direcciones fijas aún necesitan aprobación explícita.

¿Cómo puede Gateway API preservar el autoservicio de las aplicaciones?

La plataforma crea el Gateway y GatewayClass y restringe direcciones, listeners y referencias entre namespaces. Los equipos de aplicación envían HTTPRoutes sujetas a políticas de referencia, objetos de política y controles de auditoría.

¿Cómo manejas conexiones de larga duración y WebSockets?

Mide la duración de las conexiones antes de cambiar el DNS o el punto de entrada. Detén las nuevas conexiones en la ruta antigua pero permite que las existentes se drenen, usando comportamiento de reintento con doble entrada donde sea apropiado. Separa las fallas de nuevas conexiones del cierre natural en las métricas.

¿Cuándo se puede eliminar el mecanismo de reversión?

Después de que el tráfico antiguo sea cero, cada Service haya eliminado el campo, las comprobaciones de conflicto de direcciones pasen, la ventana de TTL del DNS finalice y la nueva ruta cumpla su SLO de observación. Luego elimina la instantánea conservando la evidencia de auditoría; una fecha de calendario no puede reemplazar la evidencia.

Referencias

• Desuso de ExternalIPs de Service en Kubernetes v1.36 (Blog de Kubernetes)
• Documentación de Service (Documentación de Kubernetes)
• Documentación de Control de Admisión (Documentación de Kubernetes)
• Documentación de Gateway API (Documentación de Kubernetes)

Lista de verificación para la entrevista

Separa la semántica del campo del riesgo de seguridad, luego proporciona el orden: inventario, bloqueo de adiciones, punto de entrada de reemplazo, validación en paralelo, drenaje, eliminación y reversión.

Conclusión en una sola frase

La migración de externalIPs reemplaza un punto de entrada editable por el usuario por una ruta de asignación de direcciones verificable, auditable y propiedad del administrador.

Sigue practicando

Si un clúster usa Gateway API, MetalLB y un LoadBalancer en la nube juntos, diseña un catálogo único de puntos de entrada, un modelo de propiedad de direcciones y un protocolo de reversión entre entornos.