Pregunta y contexto
Un clúster de Kubernetes de tres zonas ejecuta un servicio con un tráfico entre zonas costoso. El equipo desea que las solicitudes prefieran Pods en la zona de origen, manteniendo la disponibilidad cuando una zona carece de capacidad, el tráfico está desbalanceado o los nodos fallan. Diseña la habilitación, la distribución de endpoints, el fallback, la observabilidad y el rollback.
Qué evalúa el entrevistador
- Si separas los hints de EndpointSlice, el consumo de kube-proxy y la política de tráfico del Service.
- Si identificas prerrequisitos como el recuento de endpoints y el tráfico de origen balanceado en lugar de asumir que la misma zona siempre es mejor.
- Si diseñas fallback global, protecciones contra fallas y monitoreo de hot spots.
- Si cuantificas el costo entre zonas, la latencia, la carga de los endpoints y el riesgo de despliegue.
Preguntas de clarificación iniciales
Tráfico y objetivos
¿El tráfico de origen está distribuido uniformemente entre las zonas? ¿El objetivo es una menor latencia p95, menores costos entre zonas o residencia de datos? ¿Es preferible el acceso entre zonas antes que devolver un error?
Endpoints y escalado
¿Cuántos Pods listos existen en cada zona? ¿Podrían el escalado, una versión progresiva o un PodDisruptionBudget reducir temporalmente el recuento seguro de endpoints? ¿El Service requiere también tráfico local al nodo?
Falla y observabilidad
¿El dominio de falla es una zona, un nodo o la red? ¿Cómo detectarás una zona sobrecargada, hints faltantes o el fallback de kube-proxy? ¿Se puede habilitar la funcionalidad por Service?
Una respuesta de 30 segundos
Primero verificaría que el tráfico de origen y la distribución de endpoints cumplan con los prerrequisitos de enrutamiento, y luego habilitaría la preferencia de zona a través de hints de EndpointSlice o la configuración de traffic-distribution admitida por el Service. El plano de control y kube-proxy deben recurrir a endpoints de todo el clúster cuando fallen las condiciones de capacidad o seguridad. Monitorea los bytes entre zonas, la latencia p95, las solicitudes por zona y la carga de endpoints; realiza un despliegue canary del cambio y deshabilita la preferencia si aparece un hot spot o una falla.
Solución a profundidad
1. Separar los planos de control y de datos
El controlador de EndpointSlice utiliza la topología de los endpoints para generar hints, y kube-proxy u otro componente del plano de datos del nodo los consume. Topology Aware Routing prefiere endpoints en la zona de origen; no garantiza un enrutamiento estricto a la misma zona. Observa el cálculo del plano de control, la propagación de EndpointSlice y el comportamiento del nodo por separado.
2. Verificar los prerrequisitos
La documentación de Kubernetes recomienda al menos tres endpoints por zona; en un clúster de tres zonas, eso generalmente significa al menos nueve endpoints. Con muy pocos endpoints, el controlador podría no emitir hints. Una distribución de origen concentrada en una sola zona también puede sobrecargarla, por lo que debes validar esta suposición con el historial de tráfico y los datos de capacidad.
3. Elegir la configuración
Usa el modo de topología o la capacidad trafficDistribution admitida para la versión de Kubernetes objetivo. Por ejemplo:
apiVersion: v1
kind: Service
metadata:
name: checkout
annotations:
service.kubernetes.io/topology-mode: "Auto"
spec:
selector:
app: checkout
ports:
- port: 443
targetPort: 8443No mezcles una anotación heredada de topology-aware-hints, el modo de topología actual y campos específicos de la versión sin verificar la versión de la API, los feature gates y el comportamiento de kube-proxy.
4. Diseñar un fallback seguro
El plano de control o kube-proxy debe utilizar endpoints de todo el clúster cuando los endpoints sean insuficientes, los hints sean inválidos o la asignación sea insegura. Haz que el fallback sea observable; de lo contrario, el tráfico entre zonas podría interpretarse erróneamente como una optimización exitosa. Prueba una interrupción de toda la zona, la propagación retrasada de EndpointSlice, etiquetas de nodo incorrectas y versiones mixtas de kube-proxy.
5. Prevenir hot spots
La preferencia por la misma zona reduce el conjunto de endpoints. Monitorea solicitudes, conexiones, CPU, profundidad de cola y errores por zona. Si una zona recibe una proporción desmedida del origen o tiene muy pocos endpoints, reduce la preferencia o usa temporalmente el enrutamiento global. El escalado y las versiones progresivas deben preservar los endpoints listos y el margen de PDB en cada zona.
6. Evaluar costo y latencia
Registra juntos los bytes entre zonas, p50/p95/p99 de solicitudes, la reutilización de conexiones, la carga de endpoints y la tasa de fallas. Compara la misma ventana de tráfico antes y después de la habilitación; de lo contrario, los cambios en aciertos de caché o reintentos del cliente pueden atribuirse erróneamente al enrutamiento de topología. La reducción de costos no debe lograrse a expensas de una peor tasa de errores o latencia de cola.
7. Desplegar y revertir gradualmente
Habilita la funcionalidad en un Service no crítico o mediante un canary de una sola zona, verifica los hints de EndpointSlice, las decisiones de kube-proxy y los eventos de fallback, y luego amplía a servicios similares. El rollback elimina la preferencia y verifica los endpoints globales; conserva versiones de configuración, ventanas de métricas y evidencia de simulacros de fallas.
Ejemplo de una respuesta sólida
Trato la preferencia de topología como una optimización de rendimiento reversible. Primero valido los recuentos de endpoints y la distribución de origen, y luego permito que el controlador de EndpointSlice cree hints para el plano de datos del nodo. La escasez de endpoints, el desbalance entre zonas o componentes incompatibles activan el fallback global. Monitoreo los bytes entre zonas, la carga por zona, la latencia, los errores y la cantidad de fallbacks; realizo un canary antes de la expansión. Cualquier zona sobrecargada o fallida puede recuperar la disponibilidad deshabilitando la preferencia.
Errores comunes
- Asumir que los hints garantizan un enrutamiento estricto a la misma zona.
- Ignorar los prerrequisitos de recuento de endpoints y de fuentes balanceadas.
- Observar el costo entre zonas descuidando la sobrecarga de endpoints y la latencia de cola.
- Tratar las anotaciones heredadas, los campos de versión y los feature gates como una única API universal.
- No tener un fallback global o simulacro de fallas cuando desaparecen los hints.
- Permitir que un despliegue o reducción de escala deje a una zona por debajo de su margen seguro de endpoints listos.
Preguntas de seguimiento y respuestas
¿Por qué recurrir al fallback cuando los endpoints son escasos?
La preferencia de topología reduce el conjunto de candidatos; muy pocos endpoints aumentan el riesgo de sobrecarga y falla. Los endpoints globales preservan la disponibilidad en primer lugar.
¿Tener tres endpoints es una regla estricta?
Es una recomendación de aplicabilidad en la documentación de Kubernetes para mejorar la asignación de zonas, no una garantía absoluta para todas las cargas de trabajo. Valídala frente a los objetivos de tráfico, capacidad y fallas.
¿Qué sucede si todas las solicitudes se originan en una sola zona?
La preferencia por la misma zona puede concentrar la carga allí. Reduce la preferencia, agrega endpoints en esa zona o recurre al fallback global, y luego confirma con métricas de carga y latencia.
¿Cómo demuestras que kube-proxy consumió los hints?
Inspecciona los hints de EndpointSlice, las versiones de los componentes del nodo y la distribución real de solicitudes. Utiliza los bytes entre zonas y la tasa de aciertos de endpoints por zona para obtener evidencia de extremo a extremo, en lugar de verificar solo los objetos del plano de control.
¿El rollback requiere reconstruir el Service?
Por lo general, basta con eliminar o ajustar la preferencia de topología y verificar que EndpointSlice y el comportamiento del plano de datos del nodo vuelvan a la selección global. Mantén un simulacro de rollback y evidencia en métricas.