ADR-030: la entrada sigue con Gateway y VirtualService de Istio, sin la Gateway API de Kubernetes
Aceptado el 15/11/2026 por Andrés. Complementa ADR-008 (Istio con sidecars) y ADR-022 (fila 8: TLS de origen en `istio-ingress`).
Contexto
La entrada del demo en EKS es el gateway de entrada de Istio. Enruta por host con un Gateway y un VirtualService por subdominio (networking.istio.io/v1): api y hooks a KrakenD, auth a Keycloak y los sistemas simulados directo a sus pods. El chart istio-routing los declara.
Kubernetes tiene una API más reciente y portable para lo mismo, la Gateway API (gateway.networking.k8s.io: Gateway, HTTPRoute), que Istio también implementa. Se evaluó si el demo debía usarla.
Opciones
| Opción | A favor | En contra |
|---|---|---|
A. Seguir con Gateway y VirtualService de Istio |
Una sola familia de recursos con todo lo que Istio ya aporta (mTLS, AuthorizationPolicy, EnvoyFilter de cuota y de errores, ServiceEntry); nada que reescribir ni volver a probar; menos heterogeneidad |
No es el estándar portable entre implementaciones |
| B. Forma mínima: Gateway API ligada al proxy existente | Estándar de Kubernetes en la entrada; solo cambia el chart istio-routing |
De 3 a 4 horas de trabajo, 30 minutos más en EKS para probarla y una hora de documentos; dos APIs de enrutamiento conviviendo (la malla y los filtros siguen en recursos de Istio) |
| C. Forma pura: Gateway API de punta a punta | Estándar completo | De 6 a 8 horas; toca la entrada, la malla y las pruebas; riesgo alto a pocos días del demo |
Decisión
Opción A. La entrada del demo sigue con Gateway y VirtualService de Istio (networking.istio.io/v1). No se usa la Gateway API de Kubernetes en este demo.
Razón de Andrés, 15/11/2026: "mantengamos el ADR con Istio para tener unidad con todo lo que Istio sí nos aporta y hacemos explícita la decisión de para simplificar y evitar tanta heterogeneidad, aunque conocemos del api más reciente de Gateway, no la usamos para este demo".
Qué se sacrifica
- El estándar portable entre implementaciones: cambiar de malla o de gateway obliga a reescribir los recursos de enrutamiento. Queda como evolución: la forma mínima (opción B) toca solo
istio-routingy se puede hacer después del demo. - Los equipos que ya conocen la Gateway API no la encuentran aquí; este ADR deja dicho que es una elección y no un desconocimiento.
Se revisaría si la capa dejara de depender de Istio, o si un cliente exigiera el estándar de Kubernetes en la entrada.