TIS1105 - More than One VirtualService Exists for the Same Host

More than one VirtualService exists for the same host, which can lead to configuration conflicts and unpredictable behavior.

Recommendation: Avoid Multiple VirtualService Resources for the Same Host

To prevent configuration conflicts, merge multiple VirtualService definitions for the same host into one. Ensure a "catch-all" scenario is included to handle all possible routes for the host.

Examples

1. Two VirtualService Objects Targeting the Same Host

   First VirtualService:

   apiVersion: networking.istio.io/v1beta1
   kind: VirtualService
   metadata:
     name: virtual-service-1
     namespace: example-namespace
   spec:
     hosts:
     - "my-app.example.com"
     gateways:
     - "gateway-1"
     http:
     - route:
       - destination:
           host: "my-app-service.example-namespace.svc.cluster.local"

   Second VirtualService:

   apiVersion: networking.istio.io/v1beta1
   kind: VirtualService
   metadata:
     name: virtual-service-2
     namespace: example-namespace
   spec:
     hosts:
     - "my-app.example.com"
     gateways:
     - "gateway-2"
     http:
     - route:
       - destination:
           host: "my-app-service.example-namespace.svc.cluster.local"

   Explanation: Both VirtualService definitions reference the same host (my-app.example.com). While it is valid for VirtualService resources to share a host if they are bound to different gateways, this configuration can lead to ambiguity, especially when sidecars are involved. Sidecars do not accept this behavior, and Istio does not guarantee the order of merging configurations when multiple VirtualService definitions exist for the same host.

Recommendation

This configuration is valid only if two VirtualService resources share the same host but are bound to different gateways. It is recommended to avoid using this method, as defining the same parts in multiple VirtualService definitions can lead to conflicts. While Istio will merge the configurations, the merging order is not guaranteed, and only the first seen configuration is applied (the rest are ignored). Each VirtualService definition should include a "catch-all" scenario, which can only be defined in a definition affecting the same host.

1. Merge VirtualService Definitions into One

   Instead of defining multiple VirtualService objects for the same host, merge them into a single VirtualService to avoid conflicts.

   apiVersion: networking.istio.io/v1beta1
   kind: VirtualService
   metadata:
     name: merged-virtual-service
     namespace: example-namespace
   spec:
     hosts:
     - "my-app.example.com"
     gateways:
     - "gateway-1"
     - "gateway-2"
     http:
     - route:
       - destination:
           host: "my-app-service.example-namespace.svc.cluster.local"

   Explanation: Merging both VirtualService definitions into one ensures that there is no ambiguity in the routing behavior for the host. This way, Istio can properly manage the traffic for the host without risking conflicting configurations.

2. Define a Catch-All Route in the VirtualService

   Make sure each VirtualService definition includes a "catch-all" route to handle scenarios not covered by more specific rules.

   apiVersion: networking.istio.io/v1beta1
   kind: VirtualService
   metadata:
     name: virtual-service-catch-all
     namespace: example-namespace
   spec:
     hosts:
     - "my-app.example.com"
     gateways:
     - "gateway-1"
     http:
     - match:
       - uri:
           prefix: "/specific-path"
       route:
       - destination:
           host: "my-app-service.example-namespace.svc.cluster.local"
     - route:
       - destination:
           host: "my-app-service.example-namespace.svc.cluster.local"

   Explanation: Including a "catch-all" route ensures that all requests that do not match more specific routes are properly handled, preventing traffic from being dropped.