Split VirtualService into Delegates for Independent Team Routing - ASM

As routing rules accumulate in a single VirtualService, every change risks breaking unrelated routes, and multiple teams editing the same resource leads to conflicts. Service Mesh (ASM) supports VirtualService delegation, which lets you split routing rules across a primary VirtualService and multiple secondary VirtualServices. The primary VirtualService defines URI-prefix boundaries and delegates each prefix to a secondary VirtualService that owns the detailed routing logic for its scope.

This provides two benefits:

Reduced blast radius -- a routing change in one secondary VirtualService cannot affect routes owned by another.
Independent ownership -- mesh administrators maintain the primary VirtualService, while service teams maintain their own secondary VirtualServices.

How delegation works

A primary VirtualService matches incoming requests by URI prefix and forwards each match to a named delegate. Each delegate points to a secondary VirtualService in a specific namespace. The secondary VirtualService defines the exact match rules and route destinations within that prefix scope.

                          Primary VirtualService (bookinfo)
                          +---------------------------------+
                          |  /log*  ->  delegate: vs-1 (ns1) |
                          |  /*     ->  delegate: vs-2 (ns1) |
                          +--------+-------------+----------+
                                   |             |
                  +----------------+             +----------------+
                  v                                                v
     Secondary VirtualService (vs-1)            Secondary VirtualService (vs-2)
     +----------------------------+             +---------------------------------+
     |  /login  -> productpage    |             |  /productpage  -> productpage    |
     |  /logout -> productpage    |             |  /static/*     -> productpage    |
     +----------------------------+             |  /api/v1/products/* -> productpage|
                                                +---------------------------------+

Delegation rules

Follow these rules when you configure delegates. Violations cause routing rules to silently fail.

#	Rule	Detail
1	One direction only	Set delegate parameters only in the primary VirtualService. If both the primary and a secondary VirtualService contain delegate parameters, neither takes effect.
2	Match subset requirement	The `HTTPMatchRequest` in a secondary VirtualService must be a subset of the corresponding match in the primary VirtualService. Mismatches cause the `HTTPRoute` to not take effect.
3	Mutually exclusive with route and redirect	Delegate parameters can only be specified when the `route` and `redirect` fields in the primary VirtualService are empty.
4	Empty hosts in secondary VirtualServices	The `hosts` field in secondary VirtualServices must be empty. ASM combines the routing rules from secondary VirtualServices with those from the primary VirtualService.

Prerequisites

Before you begin, make sure that you have:

An ASM instance (version 1.8.6.4 or later) with a Container Service for Kubernetes (ACK) cluster added. For more information, see Add a cluster to an ASM instance
An ingress gateway deployed in the ASM instance. For more information, see Create an ingress gateway
The Bookinfo application deployed in the ACK cluster. For more information, see Deploy an application in an ASM instance

Step 1: Create an Istio gateway

Log on to the ASM console.
In the left-side navigation pane, choose Service Mesh > Mesh Management.
On the Mesh Management page, find the target ASM instance. Click its name or click Manage in the Actions column.
In the left-side navigation pane, choose ASM Gateways > Gateway. On the page that appears, click Create from YAML.

Select default from the Namespace drop-down list, paste the following YAML, and click Create.

   apiVersion: networking.istio.io/v1alpha3
   kind: Gateway
   metadata:
     name: bookinfo-gateway
   spec:
     selector:
       istio: ingressgateway  # Use the default Istio ingress controller
     servers:
     - port:
         number: 80           # Accept HTTP traffic on port 80
         name: http
         protocol: HTTP
       hosts:
       - "*"

Step 2: Create the primary VirtualService

The primary VirtualService defines two delegate references -- one for the /log prefix and one for the catch-all / prefix. It contains no route or redirect fields, only delegate pointers.

In the left-side navigation pane of the ASM instance details page, choose Traffic Management Center > VirtualService. Click Create from YAML.

Select default from the Namespace drop-down list, paste the following YAML, and click Create.

Order matters. ASM evaluates http entries top-down. Place more specific prefixes (like /log) before broader ones (like /).

Delegate field parameters:

Parameter	Description
`name`	Name of the secondary VirtualService to delegate to
`namespace`	Namespace where the secondary VirtualService is deployed

   apiVersion: networking.istio.io/v1beta1
   kind: VirtualService
   metadata:
     name: bookinfo
     namespace: default
   spec:
     gateways:
       - bookinfo-gateway
     hosts:
       - '*'
     http:
       - delegate:
           name: vs-1          # References secondary VirtualService vs-1 in ns1
           namespace: ns1
         match:
           - uri:
               prefix: /log    # Matches /login, /logout, and other /log* paths
       - delegate:
           name: vs-2          # References secondary VirtualService vs-2 in ns1
           namespace: ns1
         match:
           - uri:
               prefix: /       # Catch-all for remaining paths

Step 3: Create secondary VirtualServices

Each secondary VirtualService is a standalone resource that a service team can own and manage independently. The metadata.name and metadata.namespace must match the corresponding delegate reference in the primary VirtualService.

Create vs-1 (login and logout routes)

In the left-side navigation pane, choose Traffic Management Center > VirtualService. Click Create from YAML.

Select ns1 from the Namespace drop-down list, paste the following YAML, and click Create. Both /login and /logout fall within the /log prefix defined in the primary VirtualService, satisfying the match-subset requirement.

If the ns1 namespace does not exist, create it first. For more information, see Manage global namespaces.

   apiVersion: networking.istio.io/v1beta1
   kind: VirtualService
   metadata:
     name: vs-1              # Must match the delegate name in the primary VirtualService
     namespace: ns1          # Must match the delegate namespace in the primary VirtualService
   spec:
     http:                   # No hosts field -- required for delegate VirtualServices
       - match:
           - uri:
               exact: /login
           - uri:
               exact: /logout
         route:
           - destination:
               host: productpage.default.svc.cluster.local
               port:
                 number: 9080

Create vs-2 (product page, static assets, and API routes)

On the same VirtualService page, click Create from YAML again.

Select ns1 from the Namespace drop-down list, paste the following YAML, and click Create. All three match patterns fall within the / prefix defined in the primary VirtualService.

   apiVersion: networking.istio.io/v1beta1
   kind: VirtualService
   metadata:
     name: vs-2              # Must match the delegate name in the primary VirtualService
     namespace: ns1          # Must match the delegate namespace in the primary VirtualService
   spec:
     http:                   # No hosts field -- required for delegate VirtualServices
       - match:
           - uri:
               exact: /productpage
           - uri:
               prefix: /static
           - uri:
               prefix: /api/v1/products
         route:
           - destination:
               host: productpage.default.svc.cluster.local
               port:
                 number: 9080

Verify the result

Open http://<ingress-gateway-IP>/productpage in a browser. The Bookinfo product page appears, confirming that the vs-2 delegate is working. To get the ingress gateway IP address, see the "Obtain the IP address of the ingress gateway" section in Use Istio resources to route traffic to different versions of a service.
Click Sign in in the upper-right corner and enter a username and password. A successful login confirms that the vs-1 delegate is working.

Role and ownership summary

Role	Responsibility	Resource
Mesh administrator	Defines URI-prefix boundaries and delegate references	Primary VirtualService
Service team	Manages detailed routing rules for their prefix scope	Secondary VirtualService

This delegation model lets service teams deploy and update their routing rules independently, without modifying the primary VirtualService or coordinating with other teams.