The Istio Gateway is a replacement for a typical Kubernetes ingress controller rather than just an instance of an ingress controller, and has its own type of resources (virtual services). So this is a challenging problem.

Eclipse Che does permit you to configure the annotations it places on an ingress (see the config map for details), so you could use a different Ingress controller other than the default of NGINX, but Che is absolutely going to create an Ingress for each workspace to route traffic, and that's not going to work without some kind of ingress controller.

So you have a couple options, both of which involve deploying an ingress controller alongside Istio:

1. You can deploy an ingress controller and either allow it to get a separate external IP from your provider or configure it as a NodePort and route traffic to it that way. This effectively bypasses Istio for traffic going to Eclipse Che.
2. You can take advantage of the fact that an ingress controller includes a regular Kubernetes service by creating an Istio virtual service that routes traffic to the ingress controller's service based on the hostname or wildcard you've chosen for Eclipse Che. The ingress controller then routes to the Che server or the specific workspace. This adds an extra routing step to traffic going to Eclipse Che, but has the advantage that you'll leverage your existing gateway and configuration for that traffic.

Hopefully in the future Eclipse Che will support creating Istio virtual services as an alternative to creating an Ingress for each workspace, but until that's true there needs to be something to bridge the gap.