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

Question

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

<块引用>

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

它显示了这个图形（用于显示 pod 发现，而不是用于流量路由）：

我对此有点困惑，因为我不知道 Istio VirtualService 如何知道要查看哪个 Kubernetes Service。我在示例 Istio VirtualService yaml 文件中没有看到任何对 Kubernetes Service 的引用。

我推测 DestinationRules 上可以有足够的标签来深入到所需的 pod，但示例仅使用标签 v1 和 v2。单独一个版本似乎不太可能只提供所需的 pod。 （许多不同的 Services 可以在 v1 或 v2 上。）

Istio VirtualService 如何知道要关联到哪个 Kubernetes Service？

或者换一种说法，

Istio VirtualService 如何知道如何从集群中的所有 Pod 中找到正确的 Pod？

Answer 1

创建 VitualService 时，您可以在 route.destination 部分定义要查找的服务

port : 在端口上运行的服务

host : 服务名称

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 虚拟服务

Answer 2

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

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

<块引用>

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

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

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

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

所以流量不是这样路由的

Gateway -> VirtualService -> DestinationRule -> Service -> Pod，但是喜欢

Gateway -> Service，考虑来自 VirtualService 和 DestinationRule 的配置。