For applications with many microservices or numerous routing rules, a single VirtualService can become large and difficult to maintain. To address this, Service Mesh (ASM) provides a delegate mechanism that lets you split routing rules across multiple VirtualService resources. This reduces the risks associated with changing routing configurations. This topic uses the Bookinfo application as an example to demonstrate how to define routing rules for the application by using multiple VirtualServices.
Prerequisites
-
A cluster has been added to an ASM instance, and the ASM instance is version 1.8.6.4 or later.
An ingress gateway is deployed. For more information, see Create an ingress gateway.
-
An application has been deployed in the cluster that is associated with the ASM instance. For more information, see Deploy an application in an ASM instance.
Background information
In Service Mesh (ASM), you use a VirtualService to define routing rules that control how traffic is routed to services. In practice, maintaining a single, large VirtualService can be challenging. Every routing upgrade requires you to modify this VirtualService, which often leads to update conflicts, redundancy, and tight coupling in routing configurations. Any misconfiguration in the rules can affect services in the data plane cluster and may even disrupt all service access.
ASM extends the VirtualService resource with a delegate mechanism to decouple routing rules. You can split a VirtualService into a primary VirtualService and one or more secondary VirtualServices. The primary VirtualService defines the overall rules, while secondary VirtualServices define detailed routing rules for specific parts of the application. The primary VirtualService is typically managed by a central administrator, and secondary VirtualServices are managed by individual service owners. This separation of concerns significantly reduces the risk of changing routing rules and improves the efficiency of independent service deployments and upgrades.
Notes
-
ASM does not support nested Delegates. The Delegate parameter can be set only in a primary VirtualService. For example, if the Delegate parameter is set in both a primary VirtualService and a secondary VirtualService, neither the primary VirtualService nor the secondary VirtualService will take effect.
-
The
HTTPMatchRequestin a secondary VirtualService must be a subset of the corresponding match condition in the primary VirtualService. Otherwise, a conflict occurs and theHTTPRoutewill not take effect. -
You can specify the
delegatefield only when therouteandredirectfields in the primary VirtualService's HTTP route are empty. Thehostsfield of a secondary VirtualService must be empty. The routing rules from the secondary VirtualService are merged with those from the primary VirtualService.
Step 1: Configure Gateway
-
Log on to the ASM console.
-
In the left-side navigation pane, choose .
-
On the Mesh Management page, find the ASM instance that you want to configure. Click the name of the ASM instance or click Manage in the Actions column.
-
On the details page of the ASM instance, choose in the left-side navigation pane. On the page that appears, click Create from YAML.
-
Select a Namespaces, paste the following YAML content into the editor, and click Create. This topic uses the
defaultnamespace as an example.apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: bookinfo-gateway spec: selector: istio: ingressgateway # use istio default controller servers: - port: number: 80 name: http protocol: HTTP hosts: - "*"Set
numberto80so that the Bookinfo service can receive incoming or outgoing HTTP connections on port 80.
Step 2: Configure the primary VirtualService
-
Log on to the ASM console.
-
In the left-side navigation pane, choose .
-
On the Mesh Management page, find the ASM instance that you want to configure. Click the name of the ASM instance or click Manage in the Actions column.
-
On the details page of the ASM instance, choose in the left-side navigation pane. On the page that appears, click Create from YAML.
-
Select a Namespaces, paste the following YAML content into the editor, and click Create. This topic uses the
defaultnamespace as an example.The following creates
delegates for vs-1 and vs-2, where vs-1 requires requests to contain/logto access the Bookinfo service, and vs-2 requires requests to contain/to access the Bookinfo service.apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: bookinfo namespace: default spec: gateways: - bookinfo-gateway hosts: - '*' http: - delegate: name: vs-1 namespace: ns1 match: - uri: prefix: /log - delegate: name: vs-2 namespace: ns1 match: - uri: prefix: /Parameters in the
delegatefield:-
name: The name of the delegate.
-
namespace: The namespace of the delegate.
-
Step 3: Configure the child VirtualService
-
Log on to the ASM console.
-
In the left-side navigation pane, choose .
-
On the Mesh Management page, find the ASM instance that you want to configure. Click the name of the ASM instance or click Manage in the Actions column.
-
On the details page of the ASM instance, choose in the left-side navigation pane. On the page that appears, click Create from YAML.
-
Select a Namespaces, paste the following content into the editor, and click Create.
This topic uses the
ns1namespace as an example. For more information about how to create a namespace, see Manage global namespaces.apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: vs-1 namespace: ns1 spec: http: - match: - uri: exact: /login - uri: exact: /logout route: - destination: host: productpage.default.svc.cluster.local port: number: 9080-
metadata: Must be consistent with the delegate parameter of the primary VirtualService to bind the delegate parameter. In this example, the metadata is consistent with the delegate parameter of vs-1, which binds the delegate parameter of vs-1.
-
match: Specifies the filter conditions for requests. In this example,
uriis set toexact: /loginandexact: /logout. This allows you to log in to and log out of the Bookinfo service.
-
-
Again, select the
ns1Namespaces, paste the following YAML content into the editor, and click Create.apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: vs-2 namespace: ns1 spec: http: - match: - uri: exact: /productpage - uri: prefix: /static - uri: prefix: /api/v1/products route: - destination: host: productpage.default.svc.cluster.local port: number: 9080-
metadata: The value must be consistent with the delegate parameter of the primary VirtualService. This is used to bind to the delegate parameter. In this example, the value is consistent with the delegate parameter of vs-2, which means it is bound to the delegate of vs-2.
-
match: Specifies the filter conditions for a request. In this example, the request must contain /productpage, /static, or /api/v1/products.
-
Verify the results
-
In your web browser, navigate to http://<ingress gateway IP address>/productpage.
The following page is displayed. This indicates that the request to the Bookinfo service that contains the
/productpageparameter was successful, and that the VirtualService for vs-2 is configured successfully. For information about how to obtain the ASM gateway address, see Obtain the ingress gateway IP address. The page successfully loads the BookInfo Sample application and displays the product page for the book The Comedy of Errors. The Book Details section on the left lists fields such as Type, Pages, Publisher, Language, and ISBN. The Book Reviews section on the right displays multiple user reviews and star ratings. This confirms that the service mesh application is accessible through the ASM gateway. -
Click Sign in in the upper-right corner of the page. In the dialog box that appears, enter a username and password to sign in to the Bookinfo service.
The page updates to a logged-in state. This confirms that the
vs-1VirtualService is configured correctly. After you sign in, your username (for example,jason) and a sign out link appear in the upper-right corner, confirming a successful sign-in.