Why does a destination rule not take effect after it is defined? - Alibaba Cloud Service Mesh

This topic describes the issue where a destination rule does not take effect after it is defined. This topic also describes the cause of the issue and provides a solution.

Problem description

When you use a client to call a service for which a destination rule is defined, the call fails because the destination rule does not take effect.

Cause

To route a request to a service, Service Mesh (ASM) follows a specific process to search for the destination rule that is defined for the service. If the destination rule is not found in the namespaces that are searched based on the specific process, the destination rule does not take effect. ASM searches for the destination rule based on the following process:

ASM checks whether the destination rule exists in the namespace where the client that is used to call the service resides.
ASM checks whether the destination rule exists in the namespace where the service that is to be called resides.
ASM checks whether the destination rule exists in the root namespace that is named istio-system.

For example, the following YAML file is used to define a destination rule for the myservice service in the ns1 namespace. The host field indicates that the myservice service is defined in the default namespace.

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: myservice
spec:
  host: myservice.default.svc.cluster.local
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100

If you use a client that resides in the ns1 namespace to call the myservice service, the call is successful because ASM finds the destination rule of the myservice service in the ns1 namespace and uses the destination rule to route the call request.
If you use a client that resides in the ns2 namespace to call the myservice service, the call fails. ASM searches for the destination rule based on the following process:
1. The client that is used to call the myservice service resides in the ns2 namespace. ASM searches for the destination rule in the ns2 namespace. However, the destination rule is not found because it does not exist in the ns2 namespace.
2. The myservice service to be called resides in the default namespace. ASM searches for the destination rule in the default namespace. However, the destination rule is not found because it does not exist in the default namespace.
3. The root namespace of ASM is fixed as istio-system. ASM searches for the destination rule in the istio-system namespace. However, the destination rule is not found because it does not exist in the istio-system namespace.

Solution

When you define a destination rule for a service, define the destination rule in one of the following namespaces:

The root namespace of ASM
The namespace where the service resides
The namespace where the client that is used to call the service resides

Note

You can use virtual services across namespace boundaries. By default, a virtual service is visible to all namespaces regardless of the namespace where the virtual service is defined. However, you can modify the exportTo parameter to change the default setting in the YMAL file that is used to define the virtual service.