I'm running a Kubernetes cluster (v1.31.0) with Istio (v1.24.1) and need to deploy:

• A main version of multiple APIs

• Multiple feature versions of the same API

Requirements:

• Requests with a specific header key (channel-version) should route to feature versions, based on the header value

• All other requests (without this header, or with header values that do not match) should route to main versions

This should work for:

• External traffic via ingress gateway

• Internal service mesh traffic (pod-to-pod communication)

Current Setup

I have two APIs (client-api and server-api) with:

• Main versions (deployment, service, virtual service, destination rule)

• Feature versions (deployment, virtual service, destination rule - sharing the same service)

• Client-api has an endpoint that calls server-api via it's Kubernetes service DNS, on port 8080

Main version manifests:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    name: "{client/server}-api"
    app: main
  name: "{client/server}-api"
spec:
  replicas: 1
  selector:
    matchLabels:
      name: "{client/server}-api"
      app: main
  strategy: {}
  template:
    metadata:
      labels:
        name: "{client/server}-api"
        app: main
    spec:
      containers:
- ...
---
Service:
apiVersion: v1
kind: Service
metadata:
  labels:
    name: {client/server}-api
  name: {client/server}-api
spec:
  ports:
    - port: 8080
      protocol: TCP
      targetPort: 8080
  type: ClusterIP
  selector:
    name: {client/server}-api
---
VirtualService:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: vs-{client/server}-api
spec:
  exportTo:
  - .
  gateways:
  - my-ingress-gateway
  - mesh
  hosts:
  - my-loadbalancer
  - {client/server}-api.default.svc.cluster.local
  http:
  - match:
    - uri:
        prefix: /{client/server}-api/v1.0
    route:
    - destination:
        host: {client/server}-api
        port:
          number: 8080
        subset: main
---
Destination Rule:
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: dr-{client/server}-api
spec:
  host: {client/server}-api
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST
  subsets:
  - name: main
    labels:
      app: main

The feature version manifests are:

kind: Deployment
metadata:
  labels:
    name: "{client/server}-api-pr"
    app: feature
  name: "{client/server}-api-pr"
spec:
  replicas: 1
  selector:
    matchLabels:
      name: "{client/server}-api-pr"
      app: feature
  strategy: {}
  template:
    metadata:
      labels:
        name: "{client/server}-api-pr"
        app: feature
    spec:
      containers:
- ...
---
Virtual Service:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: vs-{client/server}-api-pr
spec:
  gateways:
  - my-ingress-gateway
  - mesh
  hosts:
  - my-loadbalancer
  - {client/server}-api
  http:
  - match:
    - uri:
        prefix: /{client/server}-api/v1.0
      headers:
        channel-version:
          exact: feature
    route:
    - destination:
        host: {client/server}-api
        port:
          number: 8080
        subset: feature
---
Destination Rule:
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: dr-{client/server}-api-pr
spec:
  host: {client/server}-api
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST
  subsets:
  - name: feature
    labels:
      app: feature

Current Behavior

• Requests with channel-version: feature header work correctly via the load balancer

• Requests without the header:

  • External requests reach the client-api main version correctly via ingress gateway

  • But internal calls from client-api to server-api fail (no route)

I know I have to apply the main virtual service (the one with only uri matching) last to fix the ordering.

I have checked the routes of the server-api main pod using istioctl proxy-config routes {pod name} and I can see no route exists via the subset "main". I can also see the "No Route found" error in the istio logs from client-api.

Questions

• Is this expected behavior in Istio?

• How can I achieve the desired routing behavior while maintaining separate VirtualService resources?

• Are there any configuration changes I should make to the current setup?