Debugging an Istio Traffic Policy That Isn't Working

I'd work backwards from the sidecar because that's where the routing actually happens. First, `istioctl proxy-config route` on the calling pod, filtered to the destination port. That dumps the effective Envoy route config and shows whether the 80/20 split is actually programmed into the proxy. If the route isn't there, the VirtualService isn't being picked up at all — usually a namespace, gateway, or host mismatch. Next, if the route is there but pointing to one subset, I check the DestinationRule subsets and the pod labels. `kubectl get pods --show-labels` and confirm `version: v2` is actually on the v2 pods. A subset that matches zero pods doesn't throw an error, it just gets no endpoints and Envoy routes elsewhere. After that, `istioctl proxy-config endpoints` to confirm the v2 subset has real endpoints. If endpoints are empty, that confirms the label mismatch. If everything looks right, I check for a competing VirtualService — two VirtualServices for the same host with conflicting rules can produce surprising results, and the order matters. I'd also look at the sidecar access logs to see which cluster requests are actually hitting. And `istioctl analyze` is good for catching obvious config errors before going deeper.