Istio未将反向代理流量路由至指定Runtime Pod v1问题排查

Let’s dig into why your Istio traffic isn’t routing exclusively to Runtime v1 and fix this up step by step. Based on your setup, here are the most likely culprits and how to resolve them:

1. Your reverse proxy Pod isn’t running an Istio sidecar #

Istio can only enforce routing rules for traffic that flows through its sidecar proxy (istio-proxy container). If your reverse proxy Pod doesn’t have this sidecar, it’ll bypass Istio entirely and use Kubernetes’ default Service load balancing (which is why you’re seeing traffic split between v1 and v2).

How to fix: #

• First, verify if the sidecar is present:

  kubectl get pods <your-reverse-proxy-pod-name> -o jsonpath='{.spec.containers[*].name}'
  

  Look for istio-proxy in the output.
• If it’s missing, ensure your namespace has Istio injection enabled:

  kubectl label namespace <your-namespace> istio-injection=enabled --overwrite
  

  Or add the injection annotation directly to the reverse proxy’s Pod/Deployment:

  metadata:
    annotations:
      sidecar.istio.io/inject: "true"
  

• Redeploy the reverse proxy Pod to apply the sidecar.

2. Your DestinationRule has incorrect subset selectors #

Istio uses subsets in DestinationRule to group Pods by labels. If your subset for v1 doesn’t match the exact labels on your Runtime v1 Pods, Istio can’t target them properly.

How to fix: #

• First, check the labels on your Runtime Pods:

  kubectl get pods -l app=runtime --show-labels
  

  Note the version label (or whatever label you’re using to distinguish v1/v2).
• Update your DestinationRule to match those labels exactly (case-sensitive!):

  apiVersion: networking.istio.io/v1alpha3
  kind: DestinationRule
  metadata:
    name: runtime-destination-rule
  spec:
    host: runtime-service # Must match the Kubernetes Service name for your Runtime Pods
    subsets:
    - name: v1
      labels:
        version: v1 # Match the label from your v1 Pods
    - name: v2
      labels:
        version: v2 # Match the label from your v2 Pods
  

3. Your VirtualService isn’t explicitly routing to the v1 subset #

If your VirtualService doesn’t specify the subset: v1 with a 100% weight, Istio will default to round-robin across all available subsets.

How to fix: #

• Ensure your VirtualService targets the correct Service host and routes 100% traffic to v1:

  apiVersion: networking.istio.io/v1alpha3
  kind: VirtualService
  metadata:
    name: runtime-virtual-service
  spec:
    hosts:
    - runtime-service # Must match the host in your DestinationRule (and the Service name your reverse proxy uses)
    http:
    - route:
      - destination:
          host: runtime-service
          subset: v1
        weight: 100
  

• Double-check that your reverse proxy is using this Service name (e.g., http://runtime-service) as its upstream target—if it’s using Pod IPs directly, Istio can’t intercept that traffic.

4. Istio configuration is cached or has errors #

Sometimes Istio takes a moment to sync new configurations, or there’s a subtle syntax error you missed.

How to fix: #

• Run Istio’s configuration analyzer to catch issues:

  istioctl analyze -n <your-namespace>
  

  This will flag mismatched hosts, invalid selectors, or other configuration mistakes.
• Restart your reverse proxy and Runtime Pods to force the sidecar to reload fresh configuration:

  kubectl rollout restart deployment <reverse-proxy-deployment> <runtime-v1-deployment> <runtime-v2-deployment>
  

Quick Troubleshooting Checklist #

• Reverse proxy Pod has istio-proxy container
• Runtime v1 Pod labels match DestinationRule subset selector
• VirtualService routes 100% traffic to v1 subset
• Reverse proxy uses Service name (not Pod IP) for upstream
• istioctl analyze returns no errors

内容的提问来源于stack exchange，提问作者Pranam Codur