Supongo que tienes algo como esto:

 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: review-external spec: hosts: - "*.example.com" gateways: - mygateway http: route: - destination: host: reviews.prod.svc.cluster.local subset: v2 weight: 25

En ese caso, puede usar la lista de gateways de enlace en el objeto VirtualService para eso.

Para documentos:

Cuando se omite este campo, se utilizará la puerta de enlace predeterminada (malla), que aplicaría la regla a todos los sidecars de la malla. Si se proporciona una lista de nombres de puertas de enlace, las reglas se aplicarán solo a las puertas de enlace. Para aplicar las reglas tanto a las puertas de enlace como a los sidecars, especifique mesh como uno de los nombres de las puertas de enlace.

Fuente: https://istio.io/latest/zh/docs/reference/config/networking/virtual-service/#VirtualService

Así que tienes dos opciones aquí. Puede mencionar la mesh como una de las puertas de enlace:

 [...] gateways: - mygateway - mesh http: [...]

O podría crear un segundo VirtualService sin la lista de gateways de enlace para que se ajuste de forma predeterminada a la mesh (o mencionar solo la malla como puerta de enlace si desea ser declarativo). El campo spec.hosts debe contener el host, que se menciona en el destination.host .

 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: review-mesh-internal spec: hosts: - "reviews.prod.svc.cluster.local" # must be the kubernetes service host as below gateways: - mesh #optional since it's the default http: route: - destination: host: reviews.prod.svc.cluster.local subset: v1 weight: 100

Esto trae la ventaja de que puede enrutar el tráfico desde fuera del clúster de manera diferente que desde dentro del clúster. Piense en el mantenimiento, por ejemplo, donde el tráfico de usuarios no debería llegar a un módulo específico, pero el tráfico desde el interior del clúster aún debería poder hacerlo.