Istio虚拟服务与普通Kubernetes服务的关系

Question

我正在Istio服务网格上观看Pluralsight视频。演示文稿的一部分是这样说的：

VirtualService使用库伯内特斯服务查找所有pod的IP地址。VirtualService不会通过[库伯内特斯]服务路由任何流量，但它只是使用它来获取流量可能去往的endpoint列表。

它显示了这个图形(显示pod发现，而不是流量路由):

我对此有点困惑，因为我不知道IstioVirtualService如何知道要查看哪个库伯内特斯Service。我在示例IstioVirtualServiceyaml文件中没有看到任何对库伯内特斯Service的引用。

我从理论上推测，DestinationRules上可能有足够的标签来减少到只需要的pod，但这些示例只使用标签v1和v2。仅靠一个版本似乎不太可能只提供所需的 pod。（许多不同的服务可能位于 v1 或 v2 上。

IstioVirtualService如何知道要关联到哪个库伯内特斯Service？

或者说另一种方式，

Istio 虚拟服务如何知道如何从集群中的所有 Pod 中找到正确的 Pod？

Answer 1

阿拉法特的回答是正确的。

我想从关于主机的文档中添加以下部分，这将使事情更加清楚。https://istio.io/latest/docs/reference/config/networking/virtual-service/#VirtualService

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

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

DestinationRur也是如此，其中kubernetes服务的FQDN也被定义为主机。https://istio.io/latest/docs/reference/config/networking/destination-rule/#DestinationRule

VirtualService和Destination规则是为主机配置的。VirtualService定义了流量应该去哪里（例如主机，不同版本的权重，...）和Destination规则定义了流量应该如何处理，（例如负载平衡算法和版本是如何定义的。

因此，流量不是这样路由的

网关-

网关-

Answer 2

创建虚拟服务时，您可以在< code>route.destination部分定义要查找的服务

< code>port:在端口上运行的服务

主机：服务的名称

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

所以

< code > app-pod -