为什么定义的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/v1alpha3kind: DestinationRulemetadata:  name: myservicespec:  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改变这一默认行为。