Planteamiento y alcance
Un equipo de plataforma opera un clúster compartido de Kubernetes mientras los equipos de aplicaciones despliegan servicios gRPC. La plataforma requiere un único punto de entrada, terminación TLS, enrutamiento por servicio/método/encabezado y lanzamientos canary; cada equipo de aplicaciones solo puede editar su propio Route y no puede controlar la infraestructura ni otro namespace. Diseña los recursos, la ruta de la solicitud, el límite de autorización, la observabilidad y el rollback ante fallos.
Asume que hay un controlador de Gateway API instalado, los backends se comunican mediante gRPC sobre HTTP/2 y los clientes tienen políticas explícitas de tiempo de espera y reintentos. Enfócate en los límites del plano de control entre equipos en lugar de la implementación de un proveedor específico.
Qué evalúa el entrevistador
- Si separas las responsabilidades de GatewayClass, Gateway, GRPCRoute y Service.
- Si comprendes la granularidad de coincidencia de GRPCRoute en lugar de generar YAML genérico de Ingress.
- Si manejas ReferenceGrant entre namespaces, RBAC, denegación por defecto y auditoría.
- Si explicas pesos, streams de larga duración y los riesgos de los reintentos.
- Si defines señales de estado, compuertas de rollback y fallos en el controlador o plano de datos.
Preguntas aclaratorias antes de responder
- ¿El Gateway es propiedad centralizada de la plataforma o de cada equipo? Esto cambia la asociación del Route y su aprobación.
- ¿El enrutamiento es por servicio, método, encabezado o nombre de host? La precedencia de coincidencias cambia el manejo de conflictos.
- ¿Las llamadas son unarias o streaming de larga duración? El streaming por lo general no debe reintentarse ni cortarse por solicitud.
- ¿La selección de canary es por porcentaje, tenant, encabezado o versión del cliente? Define pesos, persistencia y señales de rollback.
- ¿Puede un Service de backend estar entre namespaces o entre clústeres? Eso añade consideraciones de ReferenceGrant y chequeos de salud.
Marco de respuesta de 30 segundos
Separo el Gateway (propiedad de la plataforma) de los GRPCRoutes (propiedad de las aplicaciones), utilizando los Services como el límite de descubrimiento de backends. Un Route declara coincidencias de métodos y metadatos gRPC; las referencias entre namespaces requieren autorización explícita. El controlador expone el estado de aceptación y resolución de referencias, mientras que el plano de datos enruta por peso y evita reintentos a ciegas en streams. Inicio el canary con un tenant o un encabezado explícito, utilizo errores por método, latencia de cola y salud del negocio como compuertas de rollback, y regreso al backend estable cuando un Route o backend no es válido.
Análisis detallado paso a paso
1. Responsabilidades de recursos y flujo de datos
La plataforma crea un GatewayClass que selecciona el controlador, luego listeners, direcciones y la política TLS. Una aplicación crea un GRPCRoute en su namespace, lo asocia a un Gateway permitido mediante parentRefs y apunta a su Service. El controlador transforma las reglas aceptadas en configuración del plano de datos, haciendo coincidir el nombre de host, el servicio gRPC, el método y los encabezados antes de seleccionar backendRefs.
2. Coincidencia y manejo de conflictos
Define la precedencia entre coincidencias exactas y de reserva: una coincidencia completa de servicio/método puede tener prioridad sobre la de solo servicio, la cual puede superar a una reserva por encabezado. No permitas que dos equipos sobrescriban implícitamente el mismo padre y coincidencia. Haz visibles los conflictos mediante condiciones como Accepted y ResolvedRefs, y haz que CI las valide. Para un método desconocido, elige un UNIMPLEMENTED explícito o una alternativa estable; nunca enrutes silenciosamente a un servicio arbitrario.
3. Autorización multi-tenant
Una aplicación solo puede escribir su Route y Service. allowedRoutes limita los namespaces que pueden asociarse a un Gateway; una referencia a un backend de otro namespace requiere un ReferenceGrant aprobado por el propietario del namespace de destino. RBAC, políticas de admisión y revisiones en Git evitan que los equipos de aplicaciones modifiquen el TLS de la plataforma, los listeners o las concesiones de otro equipo. Audita quién modificó un padre, una referencia de backend o un peso.
4. Canary, streams y reintentos
Las RPCs unarias pueden enviar nuevas solicitudes al entorno estable y al canary según el peso; una RPC de streaming mantiene su ruta tras establecer la conexión. No reintentes automáticamente llamadas no idempotentes ni acumules reintentos de Gateway sobre un tiempo de espera de cliente no definido. Utiliza un encabezado explícito o una lista de tenants como clave de canary para que un tenant no sufra desviaciones aleatorias durante la depuración. Modifica los pesos en commits pequeños y registra la hora de activación.
5. Salud, estado y rollback ante fallos
El plano de datos necesita chequeos de salud de gRPC, grupos de conexiones y un tiempo de espera explícito por ruta. Si el controlador no está disponible, continúa sirviendo la última configuración aceptada pero rechaza los cambios no verificados. Si un Gateway no es aceptado, una referencia no se puede resolver o un backend no tiene endpoints, expón un estado que bloquee el lanzamiento. El rollback puede establecer el peso del canary en cero, restaurar el Route anterior o cambiar a un Gateway en espera; haz que sea idempotente.
6. Observabilidad y límites de capacidad
Registra solicitudes, errores, latencia P50/P95/P99, streams activos, reintentos y tiempo de conexión por ruta, servicio, método, estado, tenant y versión. No incluyas metadatos crudos de alta cardinalidad en las etiquetas de métricas; muéstralos y redáctalos en los logs. Las pruebas de capacidad deben cubrir conexiones, streams concurrentes, CPU para TLS, retraso de propagación del controlador y límites de conexión del backend, tanto para tráfico unario como de streaming.
Respuesta de muestra de alta calidad
Asigno al equipo de plataforma la propiedad de GatewayClass, Gateway y listeners, mientras que los equipos de aplicaciones poseen únicamente los GRPCRoutes y Services con alcance de namespace. Un GRPCRoute coincide con servicio/método y encabezados controlados; un backend entre namespaces requiere un ReferenceGrant propiedad del destino, y allowedRoutes junto con RBAC restringen la asociación.
Para el lanzamiento, distribuyo por peso las nuevas solicitudes unarias entre el backend estable y el canary. Las conexiones de streaming se asignan una sola vez al establecerse, por lo que no las corto a mitad del stream. Evito reintentos automáticos para llamadas no idempotentes y coordino los presupuestos de tiempo de espera y reintentos entre el cliente y el Gateway. El controlador expone Accepted, ResolvedRefs y la salud del backend; CI bloquea referencias inválidas o conflictos. El canary comienza con un tenant o encabezado explícito y se revierte ante errores a nivel de método, latencia de cola, streams activos o tasa de éxito del negocio, restaurando el peso anterior con un registro de auditoría.
Errores comunes
Tratar GRPCRoute como un Ingress ordinario
Ignorar la semántica de servicio/método y HTTP/2 hace que las coincidencias sean demasiado amplias. Define primero la precedencia y el comportamiento para métodos desconocidos.
Permitir que las aplicaciones editen el Gateway
Los listeners y TLS compartidos se vuelven mutables por los tenants. Utiliza allowedRoutes, RBAC, ReferenceGrant y políticas de admisión como compuertas independientes.
Reintentar a ciegas o cortar streams
Esto puede duplicar efectos secundarios o truncar conexiones largas. Separa la política para tráfico unario y de streaming según la idempotencia y la duración de la conexión.
Verificar únicamente el éxito del despliegue del controlador
Un controlador saludable no demuestra que un Route haya sido aceptado o que un backend sea utilizable. Verifica Accepted, ResolvedRefs, la salud y las señales del plano de datos.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: Dos Routes coinciden con el mismo método. ¿Qué sucede?
No dependas del orden incidental de una implementación. Restringe la propiedad con políticas de namespace y de asociación al padre, verifica conflictos en CI y trata el estado no resuelto como un fallo de lanzamiento.
Pregunta de seguimiento 2: ¿Cómo puede un canary apuntar a un tenant de forma segura?
Utiliza una coincidencia explícita de tenant o encabezado en lugar de pesos aleatorios, y registra las tasas de error por versión y tenant. El rollback primero elimina esa coincidencia.
Pregunta de seguimiento 3: ¿Un fallo en el controlador de Gateway interrumpe el tráfico?
Depende de si el plano de datos retiene la última configuración aceptada. Continúa sirviéndola mientras congelas los cambios, monitorea la antigüedad de la configuración y realiza una conmutación por error a un sistema en espera antes de que expire la ventana de seguridad.
Pregunta de seguimiento 4: ¿Por qué se requiere autorización para un backendRef entre namespaces?
Permite que un equipo envíe tráfico al Service de otro equipo. Un ReferenceGrant propiedad del destino hace que el consentimiento sea explícito, mientras que RBAC y la auditoría evitan escaladas de privilegios ocultas.