Istio虚拟服务与正常Kubernetes服务的关系

我正在观看Istio服务网格上的Pluralsight视频。演讲的一部分说：

VirtualService使用Kubernetes服务查找所有POD的IP地址。VirtualService不通过[Kubernetes]服务路由任何流量，但它只是使用它来获取流量可能到达的端点列表

并显示此图（显示pod发现，而不是流量路由）：

我对此感到有点困惑，因为我不知道Istio

VirtualService

如何知道要查看哪个Kubernetes

服务。我在示例Istio
VirtualService
yaml文件中没有看到对Kubernetes
服务的任何引用

我从理论上推测，
DestinationRules
上可能有足够的标签，以便只使用所需的pod，但示例仅使用标签
v1
和
v2
。单是一个版本似乎不太可能只提供所需的pod。（许多不同的
服务
可能在
v1
或
v2
上）

Istio
VirtualService
如何知道要与哪个Kubernetes
服务关联？

或者换一种说法,

Istio
VirtualService
如何知道如何从群集中的所有POD中找到正确的POD？
创建VitualService时，您可以在
route.destination
部分定义要查找的服务

端口
：在端口上运行的服务

主机
：服务的名称

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-service

所以

app-pod/s
->（由
app-service
->
test
virtualservice管理）
Arfat的答案是正确的

我想从关于主机的文档中添加以下部分，这将使事情更加清楚。

[…]Kubernetes用户注意：当使用短名称时（例如，“reviews”而不是“reviews.default.svc.cluster.local”），Istio将根据规则的命名空间而不是服务来解释短名称包含主机“reviews”的“default”命名空间中的规则将被解释为“reviews.default.svc.cluster.local”，而与reviews服务关联的实际命名空间无关。为避免潜在的错误配置，建议始终使用完全限定的域名而不是短域名

因此，当您编写
host:app service
并且
VirtualService
位于
default
命名空间中时，主机被解释为
app service.default.svc.cluster.local
，这是kubernetes服务的FQDN。如果应用程序服务位于另一个命名空间中，例如
dev
，则需要将主机设置为
host:app service.dev.svc.cluster.local

对于
DestinationRule
，kubernetes服务的FQDN也定义为主机。

VirtualService
和
DestinationRule
是为主机配置的。
VirtualService
定义了流量应该流向何处（例如主机、不同版本的权重等），而
DestinationRule
定义了流量应该如何处理（例如负载平衡算法以及如何定义版本）

所以交通不是这样的

网关->虚拟服务->目的规则->服务->Pod，但类似

网关->服务，考虑到来自VirtualService和DestinationRule的配置。
我认为，
路由.目的地
部分用于选择
目的地规则
。那么
VirtualService
如何与
目的地规则
关联？我们创建
种类的方法相同：
目的地nRule
将获取服务并添加路由规则，Istio有惊人的文档：