Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Evaluate Subsetting of services #271

Closed
louiscryan opened this issue Dec 11, 2017 · 1 comment
Closed

Evaluate Subsetting of services #271

louiscryan opened this issue Dec 11, 2017 · 1 comment

Comments

@louiscryan
Copy link
Contributor

@rshriram @ZackButcher @kyessenov

Istio inherits its service registry from K8S, Consul etc but we want to be able to apply customized DestinationPolicy or RoutingRules to subsets of services. While in theory we can ask deployers to push more service declarations into a service registry this is likely to be cumbersome.

In particular we need to be able to model the following concepts:

  • Route traffic based on protocol or source metadata to a subset of endpoints within a service. Common use-case is routing to a specific version.

  • Attach custom destination policy (timeouts etc.) to a subset of endpoints within a service and then choose those endpoints with a routing rule

  • Create a weighting of traffic distribution among endpoints within a service. Common use-case is A/B testing & canarying

  • Create named 'shards' of a service for hard / soft routing affinity based on some hash of protocol information

It would also be desirable for subset names to be routable using SNI

@rshriram
Copy link
Member

rshriram commented Jan 9, 2018

fixed with latest version of destination rules as per #285

@rshriram rshriram closed this as completed Jan 9, 2018
incfly pushed a commit to incfly/api that referenced this issue Jun 13, 2018
quota() needs all the attributes that check() needs
Operator may apply conditional quota using attributes in selectors.

Note:
This effectively disables quota caching and prefetching.
Quota caching was "off" by default thru config anyway, so that is not a big problem.

mixerClient::GenerateSignature should be updated to exclude non identifying attributes.
nacx added a commit to nacx/api that referenced this issue Feb 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants