I'm trying to inject an HTTP status 500 fault in the bookinfo example.
I managed to inject a 500 error status when the traffic is coming from the Gateway with:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: bookinfo
  namespace: default
spec:
  gateways:
  - bookinfo-gateway
  hosts:
  - '*'
  http:
  - fault:
       abort:
          httpStatus: 500
          percent: 100
    match:
    - uri:
        prefix: /api/v1/products
    route:
    - destination:
        host: productpage
        port:
          number: 9080Example:
$ curl $(minikube ip):30890/api/v1/products
fault filter abortBut, I fails to achieve this for traffic that is coming from other pods:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: bookinfo
  namespace: default
spec:
  gateways:
  - mesh
  hosts:
  - productpage
  http:
  - fault:
       abort:
          httpStatus: 500
          percent: 100
    match:
    - uri:
        prefix: /api/v1/products
    route:
    - destination:
        host: productpage
        port:
          number: 9080Example:
# jump into a random pod
$ kubectl exec -ti details-v1-dasa231 -- bash
root@details $ curl productpage:9080/api/v1/products
[{"descriptionHtml": ... <- actual product list, I expect a http 500
productpage.svc.default.cluster.local but I get the same behavior.I checked the proxy status with istioctl proxy-status everything is synced.
I tested if the istio-proxy is injected into the pods, it is:
Pods:
NAME                             READY   STATUS    RESTARTS   AGE
details-v1-6764bbc7f7-bm9zq      2/2     Running   0          4h
productpage-v1-54b8b9f55-72hfb   2/2     Running   0          4h
ratings-v1-7bc85949-cfpj2        2/2     Running   0          4h
reviews-v1-fdbf674bb-5sk5x       2/2     Running   0          4h
reviews-v2-5bdc5877d6-cb86k      2/2     Running   0          4h
reviews-v3-dd846cc78-lzb5t       2/2     Running   0          4hI'm completely stuck and not sure what to check next. I feel like I am missing something very obvious.
I would really appreciate any help on this topic.
This should work, and does when I tried. My guess is that you have other conflicting route rules for the productpage service defined.
The root cause of my issues were an improperly set up includeIPRanges in my minicloud cluster. I set up the 10.0.0.1/24 CIDR, but some services were listening on 10.35.x.x.