Prompt y contexto
Un clúster de Kubernetes en HA está actualizando gradualmente su plano de control de v1.35 a v1.36. Durante esta ventana de tiempo, distintas instancias de kube-apiserver pueden conocer diferentes versiones de recursos, por lo que un cliente dirigido a un servidor más antiguo puede recibir un 404 engañoso para un recurso que sí existe en un par más reciente. Diseña y explica cómo Mixed Version Proxy debe enrutar solicitudes, restringir la confianza, proporcionar observabilidad y admitir la reversión. Distingue el comportamiento Beta de Kubernetes v1.36 de la directiva estándar de desfase de versiones (version-skew policy).
Qué evalúa el entrevistador
- Separar el desfase de versiones, los cachés de descubrimiento y la visibilidad de las API en dominios de falla distintos.
- Saber que el proxy enruta solicitudes de recursos; no reemplaza la conversión de API ni la migración de almacenamiento.
- Explicar el descubrimiento de pares, el reenvío, la propagación de identidad y la prevención de bucles.
- Cubrir la seguridad de la actualización, la auditabilidad, los tiempos de espera (timeouts), los reintentos y la reversión.
Preguntas aclaratorias para hacer
- ¿Se trata de un reemplazo progresivo dentro de un único clúster o de una migración entre clústeres? Asume un solo clúster con varios servidores de API pares.
- ¿Los clientes utilizan únicamente recursos integrados de Kubernetes o también servidores de API agregados y CRD? Confirma la cobertura del proxy para versiones de recursos desconocidas.
- ¿Ya se dispone de un balanceador de carga compartido, mTLS, auditoría centralizada y métricas? Estos elementos determinan la propagación de identidad y el diagnóstico.
- ¿Cuáles son los presupuestos para latencia adicional, indisponibilidad y tiempo de reversión?
Estructura de respuesta de 30 segundos
Comienza con la falla: durante una actualización progresiva, un servidor de API antiguo puede confundir una nueva versión de recurso con un recurso inexistente. Luego describe la ruta: el servidor de API de entrada realiza el descubrimiento y una decisión local; cuando la versión es desconocida localmente, la reenvía a un par compatible, devolviendo la respuesta, el estado y la identidad de auditoría del par al emisor. Cierra con los límites: seguir la política de desfase de versiones, prohibir bucles de proxy, restringir la identidad del proxy, devolver fallas explícitas de reenvío, evitar reintentos que oculten fallas en el plano de control y revertir mediante métricas y un cambio de feature gate escalonado.
Análisis paso a paso en profundidad
1. Clasificar la solicitud y decidir si se reenvía
El servidor de API analiza el grupo, la versión, el recurso y el verbo. Si el recurso está registrado localmente, sigue la autenticación, autorización, admisión y almacenamiento locales. Si la versión solicitada es desconocida en el descubrimiento local, el servidor verifica qué pares anuncian esa versión del recurso. Reenvía solo después de que un par confirma explícitamente el soporte; de lo contrario, devuelve un error distinguible. El proxy no debe adivinar una versión ni convertir cada 404 comercial ordinario en un desencadenante de reenvío.
2. Descubrir pares, preservar la identidad y detener bucles
Los pares deben provenir de una lista controlada de membresía del plano de control o de un mecanismo de descubrimiento interno confiable. Las conexiones utilizan la identidad de servicio existente del plano de control y un canal cifrado. La solicitud reenviada transporta la identidad del usuario original, los grupos, los encabezados de autorización y el contexto de auditoría, mientras que el proxy sigue aplicando su propio límite de autorización. Agrega un marcador de salto (hop marker) o metadatos internos equivalentes; un servidor que ve el marcador no debe reenviar de nuevo, evitando un bucle de A a B y de regreso a A.
3. Gestionar la consistencia y las fallas
Una lectura puede observar brevemente diferentes cachés de descubrimiento entre los servidores de API, por lo que los clientes deben confiar en la versión del recurso del servidor y en resourceVersion. El reenvío se produce solo cuando el destino es alcanzable y compatible con la versión; los tiempos de espera, los rechazos o las respuestas con discrepancias de versión fallan rápidamente con un motivo registrado. No apliques reintentos ilimitados a las escrituras, ya que podrían duplicar efectos secundarios. Si se requiere un reintento, utiliza una clave de idempotencia o una política de reintento de cliente explícita.
4. Implementar, observar y revertir
Actualiza un servidor de API fuera de las horas pico y luego monitorea la tasa de aciertos del proxy, la latencia de reenvío, los errores de versiones desconocidas, las respuestas 5xx, la completitud de la auditoría y la convergencia del descubrimiento antes de ampliar el lote. Mixed Version Proxy está en Beta y habilitado de forma predeterminada en v1.36, pero eso no elimina la necesidad de validar la matriz de desfase de versiones de la distribución. Si las señales se degradan, detén el reemplazo, mantén el tráfico en pares con compatibilidad comprobada y, cuando sea compatible, deshabilita el feature gate y revierte el plano de control. Conserva la cadena de reenvío y la identidad original en los registros de auditoría.
Respuesta modelo
Trataría a Mixed Version Proxy como una capa temporal de compatibilidad del plano de control, no como una nueva puerta de enlace de API (API gateway). El servidor de entrada autentica, autoriza y clasifica la solicitud. Un recurso que conoce localmente sigue la ruta local; una versión de recurso desconocida localmente se reenvía solo cuando un par la anuncia explícitamente. La conexión utiliza la identidad existente del plano de control, transporta el contexto del usuario original y de auditoría, y agrega un marcador de un solo salto para evitar bucles. Se preservan el estado y la semántica de respuesta del par. Los tiempos de espera fallan rápidamente y las escrituras no reciben reintentos automáticos ilimitados.
Validaría la ruta con una actualización escalonada: registrar aciertos locales, aciertos de proxy, versión de destino, latencia, clase de error y un ID de correlación de auditoría. Pausaría el lote cuando la tasa de aciertos o los errores 5xx superen un umbral. Que esté en Beta de forma predeterminada en v1.36 no sustituye la verificación de la política de desfase de la distribución ni la cobertura de las API agregadas y las CRD. Revertir significa detener el reemplazo, restaurar el conjunto de miembros del plano de control, deshabilitar el feature gate cuando sea compatible y verificar los cachés de descubrimiento para que los clientes no continúen utilizando capacidades obsoletas.
Errores comunes
- Describir el proxy como un convertidor arbitrario de versiones de API en lugar de una ruta para versiones de recursos desconocidas.
- Decir simplemente “reenviar a un nodo más nuevo” sin descubrimiento de pares, propagación de identidad o protección contra bucles.
- Reenviar cada 404, convirtiendo recursos faltantes genuinos en tráfico del plano de control.
- Reintentar escrituras incondicionalmente y crear efectos secundarios duplicados.
- Observar solo la latencia promedio sin tener en cuenta la convergencia del descubrimiento, la integridad de la auditoría o las restricciones de desfase.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Se pueden reenviar automáticamente por proxy los servidores de API agregados o las CRD?
Confirma si ese recurso está dentro del alcance implementado de Mixed Version Proxy. Los servidores de API agregados tienen límites independientes de descubrimiento, autenticación y disponibilidad; el soporte para recursos integrados no implica soporte para ellos. Proporciona una matriz de capacidades y una ruta explícita de falla rápida para recursos no compatibles.
Pregunta de seguimiento 2: ¿Cómo evitas que el reenvío amplifique una interrupción en el plano de control?
Utiliza un marcador de un solo salto, plazos (deadlines), límites de concurrencia y un disyuntor (circuit breaker). No reintentes indefinidamente en el origen. Emite alertas sobre la tasa de aciertos del proxy, errores en el destino y profundidad de la cola, y permite que el controlador de actualización pause un lote cuando esas señales crucen los umbrales.
Pregunta de seguimiento 3: ¿Qué sucede si el caché de descubrimiento del cliente está desactualizado?
El cliente continúa siguiendo las reglas de descubrimiento y desfase de versiones de Kubernetes. El reenvío del lado del servidor puede reducir los 404 falsos durante una actualización progresiva; no puede almacenar en caché permanentemente nuevos recursos para los clientes ni reemplazar la migración de versiones de API. Haz que el cliente redescubra y utilice una versión de API explícita cuando sea necesario.