Who "owns" VirtualService's and DestinationRule's

Hi!

We’re starting to think about how to organize our VirtualService and DestinationRule resources in Kubernetes. Currently, most of our “services” consist of multiple Kubernetes services, and live in their own namespace. So a look at our pods might be:

$ kubectl --context=$PRODUCTION get pods
NAMESPACE      NAME
foo-production cloudsql
foo-production memcached
foo-production web
...
bar-production elasticsearch
bar-production memcached
bar-production redis
bar-production web
...
baz-production redis
baz-production web

Assuming that foo-production/web and bar-production/web both call baz-production/web, what should the VirtualService look like?

What about the timeout rules for foo and bar? It seems like they must live in the VirtualService rule for baz. I don’t immediately see a way to differentiate between the two clients. Even if there was a way, this would likely become unscalable for large deployments.

Also related: Organizing VirtualServices and Gateways (x-post)

Thanks,
Michael

1 Like