0
399
VisualizaçõesRelación del servicio virtual de Istio con el servicio normal de Kubernetes
Estoy viendo un video de Pluralsight en la red de servicios de Istio. Una parte de la presentación dice esto:
VirtualService usa el servicio Kubernetes para encontrar las direcciones IP de todos los pods. VirtualService no enruta ningún tráfico a través del servicio [Kubernetes], sino que solo lo usa para obtener la lista de puntos finales a los que podría ir el tráfico.
Y muestra este gráfico (para mostrar el descubrimiento del pod, no para el enrutamiento del tráfico):
Esto me confunde un poco porque no sé cómo un Istio VirtualService sabe qué Service de Kubernetes mirar. No veo ninguna referencia en los archivos yaml de Istio VirtualService de ejemplo a un Service de Kubernetes.
He teorizado que DestinationRules podría tener suficientes etiquetas para llegar solo a los pods necesarios, pero los ejemplos solo usan las etiquetas v1 y v2 . Parece poco probable que una versión sola proporcione solo los pods necesarios. (Muchos Services diferentes podrían estar en v1 o v2 ).
¿Cómo sabe un Istio VirtualService a qué Service de Kubernetes asociarse?
o dicho de otra manera,
¿Cómo sabe Istio VirtualService cómo encontrar los pods correctos de todos los pods del clúster?
2 Respostas
Responde à pergunta0
Al crear un VirtualService, define qué servicio buscar en la sección route.destination
port : servicio que se ejecuta en el puerto
host : nombre del servicio
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: test spec: hosts: - "example.com" gateways: - test-gateway http: - match: - uri: prefix: / route: - destination: port: number: 80 host: app-serviceasi que,
app-pod/s -> (administrado por) app-service -> servicio virtual de test
0
La respuesta de Arfat es correcta.
Quiero agregar la siguiente parte de los documentos sobre el host, lo que debería aclarar aún más las cosas. https://istio.io/latest/docs/reference/config/networking/virtual-service/#VirtualService
[...] Nota para los usuarios de Kubernetes: cuando se utilizan nombres cortos (por ejemplo, "revisiones" en lugar de "reviews.default.svc.cluster.local"), Istio interpretará el nombre corto en función del espacio de nombres de la regla, no el servicio. Una regla en el espacio de nombres "predeterminado" que contiene un host "revisiones" se interpretará como "reviews.default.svc.cluster.local" , independientemente del espacio de nombres real asociado con el servicio de revisiones. Para evitar posibles errores de configuración, se recomienda utilizar siempre nombres de dominio completos en lugar de nombres cortos.
Entonces, cuando escribe host: app-service y VirtualService está en el espacio de nombres default , el host se interpreta como app-service.default.svc.cluster.local , que es el FQDN del servicio kubernetes. Si el servicio de aplicaciones está en otro espacio de nombres, digamos dev , debe configurar el host como host: app-service.dev.svc.cluster.local .
Lo mismo ocurre con DestinationRule , donde el FQDN de un servicio de kubernetes también se define como host. https://istio.io/latest/docs/reference/config/networking/destination-rule/#DestinationRule
VirtualService y DestinationRule están configurados para un host. VirtualService define a dónde debe ir el tráfico (por ejemplo, host, pesos para diferentes versiones, ...) y DestinationRule define cómo se debe manejar el tráfico (por ejemplo, algoritmo de equilibrio de carga y cómo se definen las versiones).
Entonces el tráfico no se enruta así
Gateway -> VirtualService -> DestinationRule -> Servicio -> Pod, pero como
Puerta de enlace -> Servicio, teniendo en cuenta la configuración de VirtualService y DestinationRule.