Recommendations on ingress/egress Gateways/VirtualService architectures

Networking
1

Hi team,

We are looking for architecture guides, recommended patterns on how to get ingress and egress Gateways and VirtualServices setup across bunch of namespaces. Hesitation has to do with topologies of Gateways and VirtualServices and decision making, the whys, around that. Should we go with one/many in istio namespace, should we have one Gateway/VirtualService in every namespace, should we have one or many VirtualServices at all, and mos important - how and why we should consider different topologies.

Could not find much in the official istio documentation. There are some pros/cons by people here and there yet not much on decision making and recommended topologies.

For example, here - Istio-ingressgateway controller and namespaces

As a better solution design, you should create multiple ingress gateway in each namespace. All this gateways use/refer the same istio-ingressgateway deployed in istio-sytem namespace. The namespace should be a boundary/container fronted by gateway exposing different virtual services deployed along with destination rules and deployments.

This sounds good, yet does not covers the “whys” and leaves one/many VIrtualServices pros/cons unanswered.

Could you recommend any doco on the above?

3

im actually working on a blog about this exact topic. VirtualServices dont really apply here as they are the network configuration you need to route to your applications. You create as many as you need for your network topology.

As for gateways it really depends on the topology you / your company are used to. Do you just deploy 1 nginx-ingress? Do you have many? Do you run multiple products across multiple teams in the same cluster? These all help to determine a best fit.

My guidelines would be to add gateways when you want to expose APIs across teams or products to consumers outside of your team. It shields the client from the internals and provides a clean consistent entrypoint. It can front many microservices which you will route to using VirtualServices. As for which namespace you deploy it into, i would recommend placing the gateways in its own namespace if it fronts applications from multiple namespaces. or in the namespace your application resides.