本文介绍定义的DestinationRule失效的问题现象、问题原因和解决方案。

问题现象

为服务部署DestinationRule后,使用客户端调用服务,发现DestinationRule失效,调用服务失败。

问题原因

ASM路由一个请求时,会根据固定查找过程查找DestinationRule去完成路由。如果您的DestinationRule部署在查找过程之外的命名空间,则DestinationRule会失效。查找过程如下所示:
  1. 从客户端命名空间查找,即从发起调用的客户端所在的命名空间查找是否存在相应的DestinationRule。
  2. 从服务命名空间查找,即从被调用的服务所在的命名空间查找是否存在相应的DestinationRule。
  3. 从ASM根命名空间(istio-system)查找,即从istio-system命名空间查找是否存在相应的DestinationRule。
例如,使用以下YAML文件在ns1命名空间中定义了myservice服务的DestinationRule。从 host字段得知,myservice服务是部署在default命名空间。
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: myservice
spec:
  host: myservice.default.svc.cluster.local
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
  • 如果您在ns1命名空间发起对myservice服务的调用,由于myservice的DestinationRule也定义在ns1命名空间中,所以可以查找到可用于完成路由的DestinationRule,最终可以调通服务。
  • 如果您在ns2命名空间发起对myservice服务的调用,则对myservice服务的调用将会失败。存在以下DestinationRule查找过程:
    1. 发起调用请求的客户端位于ns2命名空间,因此会从ns2命名空间查找相应的DestinationRule,但是ns2命名空间中并不存在相应的DestinationRule,查找会失败。
    2. 被调用的myservice服务是位于default命名空间,因此从default命名空间查找相应的DestinationRule,但是default命名空间中并不存在相应的DestinationRule,查找会失败。
    3. ASM的根命名空间固定为istio-system,因此从istio-system命名空间查找相应的DestinationRule,但是istio-system命名空间中并不存在相应的DestinationRule,查找会失败。

解决方案

部署DestinationRule时,您需要将DestinationRule部署在以下命名空间中:
  • ASM根命名空间。
  • 服务所在的命名空间。
  • 发起调用的客户端所在的命名空间。
说明 VirtualService不存在命名空间的限制。VirtualService无论在哪个命名空间定义,默认在所有命名空间都可见,除非在YAML文件中通过 exportTo改变这一默认行为。