<p>Currently, we successfully setup Istio to create a couple ingress-gateways like api.example.com and app.example.com, that route traffic to a variety of services with destination rules, etc. In addition to this, we would love to use Istio's features for internal-only APIs, but we are unsure of how to set something like this up. Is it possible to use Istio's Gateway and VirtualServices CRDs to route traffic without exiting the cluster? If so, how would we go about setting that up?</p>

<p>Istio gateways are for traffic coming into the cluster or traffic leaving out the cluster. <strong>For traffic inside the cluster you should not use ingress/egress gateways</strong>. If you have configured Istio in the cluster to create a service mesh then you get all these <a href="https://istio.io/docs/concepts/what-is-istio/#core-features" rel="nofollow noreferrer">benefits</a> because Istio will inject a sidecar <a href="https://istio.io/docs/setup/additional-setup/sidecar-injection/" rel="nofollow noreferrer">envoy</a> for all your services inside the cluster. It's this sidecars which provides all the benefits of the mesh.When you use ingress or egress gateway you are actually using the sidecar deployed as ingress or egress gatway.You can use virtual service, destination rule, service entries, sidecars etc without a gateway because at that point you will using the sidecars deployed alongside your application pods.</p>

<p>Here is an example of virtual service:</p>

<pre><code>apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v3
</code></pre>

<p>The virtual service hostname can be an IP address, a DNS name, or, depending on the platform, a short name (such as a Kubernetes service short name) that resolves, implicitly or explicitly, to a fully qualified domain name (FQDN). You can also use wildcard (”*”) prefixes, letting you create a single set of routing rules for all matching services. Virtual service hosts don’t actually have to be part of the Istio service registry, they are simply virtual destinations. <strong>This lets you model traffic for virtual hosts that don’t have routable entries inside the mesh</strong>.</p>
