Pregunta y escenario
Diseñe un Kubernetes Gateway compartido. Un equipo de plataforma es propietario del Gateway y de la infraestructura de balanceo de carga; los equipos de aplicaciones son propietarios de los nombres de host, puertos, HTTPRoutes y certificados en sus namespaces. Asuma 20 equipos con 50 listeners cada uno, o alrededor de 1,000 dominios, mientras que un solo Gateway tiene un límite base de 64 listeners.
Explique cómo dividir los listeners de un único Gateway gigante en ListenerSets, autorizar la vinculación entre namespaces, mantener el tráfico estable durante conflictos y exponer el estado para que los equipos puedan distinguir configuraciones Accepted, Programmed o Conflicted.
Qué está evaluando el entrevistador
Límites de recursos y delegación
Una respuesta sólida separa la infraestructura compartida, la configuración de los tenants y la vinculación de rutas, explicando luego por qué los equipos de aplicaciones no deben editar directamente el Gateway de la plataforma.
Conflictos y valores predeterminados seguros
Indique la denegación por defecto de ListenerSets, los orígenes de namespaces permitidos, la precedencia determinista de nombres de host y los límites de referencia de certificados.
Consistencia del controlador
Cubra watches, fusión (merging), validación, condiciones de estado y reintentos. Un objeto YAML por sí solo no significa que el plano de datos esté programado.
Escala y migración
Compare un solo Gateway, un Gateway por tenant y las anotaciones de Ingress. Explique cuándo la complejidad de ListenerSet vale la pena por la delegación y la interoperabilidad.
Preguntas de clarificación antes de responder
- ¿Los 1,000 dominios comparten una sola dirección de balanceador de carga o cada equipo necesita un punto de entrada aislado?
- ¿Los equipos de aplicaciones pueden administrar sus TLS Secrets o la plataforma aprueba los certificados?
- ¿La vinculación entre namespaces debe permitir todos los namespaces, un selector de etiquetas o solo el mismo namespace?
- ¿Una configuración antigua debe seguir prestando servicio ante un conflicto o una nueva configuración puede tomar el control?
- ¿Qué tan rápido debe reflejar los cambios el controlador y se requiere replicación entre clústeres?
- ¿HTTPRoute, TLSRoute y otros tipos de rutas comparten el mismo límite de autorización?
Estructura de respuesta de 30 segundos
“Permitiría que el equipo de plataforma cree el Gateway y deniegue ListenerSets por defecto, utilizando luego allowedListeners para seleccionar los namespaces permitidos. Cada equipo de aplicaciones envía un ListenerSet y rutas en su propio namespace. El controlador valida ParentRef, hostname, puerto, protocolo, referencias a certificados y AllowedRoutes; luego fusiona los listeners priorizando el Gateway padre en primer lugar, el tiempo de creación más antiguo en segundo lugar y el orden de namespace/nombre en tercer lugar. Un conflicto se marca como Accepted=False y Conflicted=True y no puede reemplazar a un listener activo. El plano de datos se programa únicamente a partir de un agregado validado, mientras que las condiciones de estado y las métricas distinguen los estados de rechazo, conflicto, no programado y programado”.
Respuesta detallada paso a paso
Paso 1: Estimar la escala y elegir recursos
Veinte equipos multiplicados por 50 listeners representan alrededor de 1,000 puntos de entrada. Colocar las 1,000 declaraciones en un solo Gateway genera contención de escritura en un único objeto, permisos amplios y recalculos repetidos del controlador. Los ListenerSets dividen la configuración propiedad de los equipos en recursos independientes; el Gateway conserva la dirección de la plataforma, la clase y la política de vinculación.
Paso 2: Establecer el protocolo de autorización
allowedListeners es la puerta de seguridad. None no acepta ningún ListenerSet por defecto; la plataforma puede elegir Same, una etiqueta Selector o All. Un ListenerSet utiliza parentRef para nombrar al Gateway. El controlador lo incluye solo cuando ambas partes autorizan la relación, la referencia es válida y la selección de namespaces lo permite.
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: shared-gateway
spec:
allowedListeners:
namespaces:
from: Selector
selector:
matchLabels:
gateway-access: shared
---
apiVersion: gateway.networking.k8s.io/v1
kind: ListenerSet
metadata:
name: team-a-listeners
namespace: team-a
spec:
parentRef:
name: shared-gateway
namespace: platform
listeners:
- name: app-a
hostname: app-a.example.com
protocol: HTTPS
port: 443Paso 3: Definir reglas de fusión y conflictos
Combine los listeners del Gateway con los listeners de ListenerSets autorizados y luego determine la identidad a partir del puerto, el protocolo y el nombre de host aplicable. Resuelva los conflictos de forma determinista: el Gateway padre gana; luego gana el ListenerSet más antiguo; los empates restantes se resuelven por orden de namespace/nombre. Marque los recursos perdedores como Conflicted en lugar de reemplazar silenciosamente el tráfico activo.
Paso 4: Aislar rutas y certificados
El allowedRoutes de ListenerSet limita qué namespaces pueden vincular rutas. Una ruta utiliza parentRefs para apuntar a una sección de ListenerSet. La política de la plataforma restringe las referencias a TLS Secrets, separando la aprobación de certificados del permiso de despliegue de la aplicación. Un equipo puede editar su propio ListenerSet y Secret, pero no puede usar ParentRef para leer el recurso de otro tenant.
Paso 5: Lograr la convergencia del controlador
Observe Gateway, ListenerSet, Route, etiquetas de namespace y Secrets, y construya un modelo deseado agrupado por Gateway. Desduplique y aplique debounce a los eventos, valide el agregado y luego programe el balanceador de carga. Devuelva las condiciones Accepted, Programmed, ResolvedRefs y Conflicted. Los reintentos son idempotentes; el último estado deseado permanece hasta que la nueva configuración se programe con éxito.
Paso 6: Comparar alternativas y rutas de falla
Un Gateway por tenant simplifica los límites de permisos, pero multiplica las direcciones, los balanceadores de carga y los costos de certificados. Un solo Gateway con anotaciones es económico, pero carece de un esquema compartido, semántica de conflictos e interoperabilidad entre implementaciones. Cuando el plano de control de ListenerSet no esté disponible, mantenga la última instantánea en estado Programmed y rechace nuevos listeners desconocidos. Si el Gateway padre desaparece o ParentRef se vuelve inválido, marque a los elementos secundarios como no aceptados y reconcilie después de la recuperación.
Respuesta de muestra de alta calidad
“Trataría al Gateway como un límite compartido propiedad de la plataforma y a los ListenerSets como declaraciones propiedad de los tenants. La plataforma configura GatewayClass, direcciones y allowedListeners con denegación por defecto; solo los namespaces etiquetados con gateway-access=shared pueden vincularse. Cada equipo envía su propio ListenerSet, HTTPRoute y referencia de certificado.
En cada evento, el controlador valida ParentRef, autorización de namespace, puerto/protocolo/hostname, AllowedRoutes y referencias a Secrets antes de fusionar. El Gateway padre gana los conflictos, seguido por la hora de creación del ListenerSet y el orden de namespace/nombre. Los perdedores reciben Accepted=False y Conflicted=True y no pueden tomar el control del tráfico activo. Solo un agregado validado programa el balanceador de carga, y Programmed significa que el plano de datos lo ha aplicado.
Para 20 equipos por 50 listeners, unos 1,000 registros, la división de recursos evita la contención de escritura en un solo objeto y los permisos centralizados. Durante el tiempo de inactividad del controlador, el plano de datos sirve la última instantánea estable y rechaza adiciones en conflicto. Si un tenant necesita una dirección aislada, un límite de cumplimiento o un dominio de falla separado, usaría Gateways individuales y asumiría el costo de infraestructura”.
Errores comunes
- Permitir que cada equipo edite el Gateway → las configuraciones se sobreescriben entre sí y los permisos son amplios → la plataforma posee el Gateway, los tenants poseen los ListenerSets.
- Permitir todos los namespaces por defecto → cualquier tenant puede solicitar ingress compartido → usar None por defecto, luego restringir con Same o Selector.
- Dejar que la última escritura gane → un nuevo listener puede secuestrar un nombre de host → usar precedencia determinista y marcar a los perdedores como en conflicto.
- Comparar únicamente el nombre de host → diferentes protocolos aún pueden colisionar → usar puerto, protocolo y nombre de host aplicable de manera conjunta.
- Pasar nombres de Secrets directamente al plano de datos → fuga de certificados o privilegios entre namespaces → validar primero las referencias y la autorización.
- Reprogramar inmediatamente ante cada evento → estados inválidos transitorios causan fluctuaciones excesivas (churn) → aplicar debounce, fusionar de forma idempotente, cambiar tras el éxito y retener una instantánea.
- Exponer únicamente Ready en el estado → los tenants no pueden distinguir el rechazo de un conflicto o de un retraso en la programación → usar las condiciones Accepted, Programmed, ResolvedRefs y Conflicted.
- Tratar a ListenerSet como una escala ilimitada → los controladores y balanceadores de carga aún tienen límites → fragmentar (shard) por Gateway, establecer cuotas por tenant y monitorear la convergencia.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: Dos equipos envían el mismo hostname y puerto. ¿Quién gana?
El Gateway padre gana. Entre ListenerSets, gana el tiempo de creación más antiguo; un empate restante se resuelve por orden de namespace/nombre. El perdedor permanece visible con Conflicted y no puede alterar el resultado mediante la sincronización de reintentos.
Pregunta de seguimiento 2: ¿Cómo puede la plataforma congelar a un tenant temporalmente?
Eliminando la etiqueta de su namespace o restringiendo el selector allowedListeners. El controlador marca el ListenerSet como no aceptado mientras retiene la última instantánea. Registre el congelamiento para auditoría y vuelva a validar tras la recuperación en lugar de confiar ciegamente en el objeto antiguo.
Pregunta de seguimiento 3: Un ListenerSet tiene 64 listeners. ¿Puede crecer más?
El límite de la implementación sigue aplicando; la capacidad total no es infinita. Divida al tenant entre varios ListenerSets y Gateways con cuotas. Si el aislamiento de direcciones o certificados importa más que compartir recursos, utilice múltiples Gateways.
Pregunta de seguimiento 4: ¿Cómo se rota un TLS Secret sin causar una interrupción del servicio?
Supervise la versión del Secret, valide su cadena, nombre de host y caducidad, y actualice Programmed solo después de que el plano de datos confirme el nuevo certificado. Conserve el certificado antiguo durante un período de gracia; en caso de fallo, continúe sirviendo la última versión que funcionó correctamente y genere una alerta.
Pregunta de seguimiento 5: ¿Puede una nueva Route reemplazar el tráfico en vivo mientras el controlador se reinicia?
No. Persista o reconstruya el estado deseado mientras el plano de datos sirve la última instantánea exitosa. Tras el reinicio, recalcule las referencias y los conflictos, y luego cambie una sola vez a una versión de configuración observable.
Fuente 1: Guía de usuario de Gateway API ListenerSet
La guía define el uso multi-tenant delegado de ListenerSet, el límite de 64 listeners, allowedListeners, parentRef y la precedencia de conflictos. Estos hechos fundamentan el modelo de recursos, el protocolo de autorización, el manejo de conflictos y el diseño de estados.
Fuente 2: GEP-1713
GEP-1713 describe la contención de recursos, la gestión entre namespaces y los casos de uso con grandes volúmenes de dominios, y especifica las reglas de fusión del Gateway padre, tiempo de creación y orden léxico. La estimación de capacidad y las alternativas utilizan estas restricciones.
Fuente 3: Notas de la versión de Kubernetes Gateway API v1.5
Las notas de la versión registran el paso de ListenerSet a Standard y su enfoque en multi-tenancy, listeners delegados y el soporte para más de 64 listeners. Esta respuesta transforma ese cambio público en decisiones de migración y gobernanza.
Fuente 4: Guía pública de entrevistas de diseño de sistemas
La guía pública enfatiza la aclaración de requerimientos, la discusión sobre escala y fallas, y la explicación de compensaciones (trade-offs). Las aclaraciones, la estimación, los seguimientos sobre conflictos y las alternativas entrenan esas señales observables de la entrevista.