-
Notifications
You must be signed in to change notification settings - Fork 327
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
feat(kuma-cp): CircuitBreaker proposal #751
Conversation
``` | ||
So circuit breaker in Envoy is a bunch of thresholds which prevents service from opening more new connections and create more new requests than configured. Also, it could limit the number of retries that happen in parallel. | ||
|
||
That functionality of Envoy doesn't allow implementing design pattern described above. In order to make it work there is another useful Envoy feature called `cluster.OutlierDetection`: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We use outlier detection already for passive healthchecks https://kuma.io/docs/0.5.0/policies/health-check/ (check ClusterWithHealthChecks
method). I think it makes sense to add more settings to passive healthchecks or get rid of passive HC and create Circuit Breaker.
"retry_budget": "{...}", | ||
"track_remaining": "...", | ||
"max_connection_pools": "{...}" | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This configuration is also important and can be a blocker when adopting Kuma. Especially max_connections
@subnetmarco looks like we have several ways to implement CircuitBreaker:
Do we have any notion what users expect from Kuma when it comes to Circuit breakers? |
I suggest that we add the |
Summary
An initial version of the proposal for the new policy "CircuitBreaker"