I’m trying to figure out the best relationship between Gateways and VirtualServices.
The Gateway can be configured to respond for multiple services based on hostname and there doesn’t seem to be anything preventing the usage of a single Gateway for any number of VirtualServices. My question is: what is the best practice when it comes to this? Should each VirtualService have its own Gateway, or should there be a single Gateway be used for all VirtualServices within a namespace (or cluster)?
Hi Erick, based on what we’ve seen out in the wild, there are certainly different permutations possible. But I think it comes down to “boundaries”. What I would say is that the best approach is to follow either namespace or “workload” boundaries you have already established.
By workload I mean, in the abstract, there may be a single hostname that maps to multiple Kubernetes Services. Those services may all encompass a single logical workload. A workload could map to teams and/or namespaces.
It’s easy to end up in a situation where multiple Gateways, improperly configured, could stomp all over each other and have competing rules. So the most scalable approach would be to organize “workloads” by namespaces, and use a “Gateway per namespace” approach. But again, that advice is heavily reliant on how you’ve organized your underlying Services.
Should multiple Gateways that target the same ingressgateway be able to use a wildcard hostname?
With Cloud Run on GKE the knative-ingress-gateway is wildcard and uses the default GKE Istio ingressgateway and when I have another Gateway with a wildcard host they seem to conflict with eachother.