<p>I have couple of services named <code>svc A</code>  and <code>svc B</code> with request flow as follows:</p>

<pre><code>svc A --&gt; svc B
</code></pre>

<p>I have injected sidecar with <code>svc B</code> and then added the routing rules via <code>VirtualServices</code> object as: </p>

<pre><code>---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: b
  namespace: default
spec:
  hosts:
  - b.default.svc.cluster.local
  http:
  - route:
    - destination:
        host: b.default.svc.cluster.local
    fault:
      abort:
        percentage:
          value: 100
        httpStatus: 403
</code></pre>

<p>These rules are only applied when <code>svc A</code> has a sidecar istio proxy. Which makes me think if we need to have istio proxy on the client side as well? I was expecting that the service for which I added rules should <strong>only</strong> have the sidecar. I can't think of any technical requirement to have it along side <code>svc B</code>.</p>

Qasim Sarfraz
<p>Yes, Service A needs a sidecar. It's confusing I admit, but the way to think of the VirtualService resource is "where do I find the backends I want to talk to and what service should they appear to provide me?" A's sidecar is its helper which does things on its behalf like load-balancing, and in your case fault injection (Service B is reliable; it's Service A that wants it to seem unreliable).</p>

<p>The comments that A and B both need sidecars in order to communicate at all aren't correct (unless you want mTLS), but if you want the mesh to provide additional services to A, then A needs a sidecar.</p>
