Best practices for storing Istio config objects

Hi there folks,

Is there a recommended namespace to store your Istio config objects? For example, Gateways, VirtualServices, AuthPolicies, etc.

Most of the rIstio esources are namespaced, so we can store them in a namespace together with our deployments.

We could also create a separate namespace only for istio config. Similar to istio-system, we could create an istio-config ns that would hold all the Gateways, VirtualServices, etc. influencing our cluster.

Is there a recommended best practice for configuring Istio? Do you store your istio configs together with your applications in various namespaces, or do you prefer to store them separately? Is there a hybrid, third way?

Any thoughts also from the Istio developers and maintainers?

I moved my Gateways into a separate namespace, because i have a bunch of wildcard domains + certs that are being used by services in multiple namespaces.

VirtualServices and DestinationRules are bundled with my Deployments

Hi erSitzt,

Would you mind elaborating on the last sentence?

I’m trying to figure out how to manage VirtualServices… Should we have one for each release? Or should we have just one for the service? How would canary release work? How would teams customize the VirtualService? etc.

Your elaboration, should you find time to respond, could help steer me in the right direction.

Thanks,
jaid