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

[feature request] connect: service-defaults/service-resolver support for upstream connection limits #9631

Closed
chrisboulton opened this issue Jan 25, 2021 · 5 comments
Labels
theme/connect Anything related to Consul Connect, Service Mesh, Side Car Proxies thinking More time is needed to research by the Consul Contributors type/enhancement Proposed improvement or new feature

Comments

@chrisboulton
Copy link
Contributor

chrisboulton commented Jan 25, 2021

Feature Description

#6829 added support for configuring Envoy's circuit breaker settings for max connections/pending requests/concurrent requests for upstreams as part of the upstream configuration on a service (proxy.upstreams[*].config), however deferred the addition of these to central configs.

This means as of today there's no configurability for upstream services provided through the discovery chain, which includes ingress gateways, etc. Because (TMK) for upstreams via the discovery chain you also can't use an escape hatch, we've hit a critical blocker with our Consul Connect/Envoy rollout, as we need to adjust these limits (primarily we need max connections > the default of 1,024 for a heavily trafficked service)

I'm raising this feature request but actually have changes locally that I'd love to contribute upstream that allow configuration of these via a service-defaults entry:

Kind      = "service-defaults"                                          
Name      = "web"       
Protocol  = "http"

Limits = {
  MaxConnections        = 200
  MaxPendingRequests    = 201
  MaxConcurrentRequests = 202
}

There was some discussion by @banks and @crhino in the mentioned PR with respect to the right place to implement configurability for these, either in service-defaults or via a service-resolver. Before I finalise these changes and raise a PR, I wanted to kick off a discussion to make sure I'm aligned to y'alls vision for this:

  • Is service-defaults where you see this being configurable, or should it fall under service-resolver?
  • Would you expect this to be supported for proxy-defaults for a "set once for all services" ability?
  • Does Limits make sense? For me, it's confusing as I'd expect it to be the limits for each of my web service instances but actuality, it's the limits for the upstreams to my service. Does UpstreamLimits make more sense?
  • Should the configurability of these at a proxy config/upstreams layer (where these are supported today) be deprecated in favour of configuration of these via config entries?
  • There's a subtle difference in the behaviour of this: today at the proxy upstream layer, service-A basically gets to decide what its upstream limits for talking to service-B are. With what I've implemented, all upstreams of service-B would be configured equally - is that okay?
  • If I have a service-defaults for Limits.MaxConnections and Limits.MaxPendingRequests, but then a proxy upstream config for just Limits.MaxConnections, would you expect the resulting configuration to merge?
@jsosulska jsosulska added theme/connect Anything related to Consul Connect, Service Mesh, Side Car Proxies type/enhancement Proposed improvement or new feature labels Feb 9, 2021
@rboyer rboyer added the thinking More time is needed to research by the Consul Contributors label Feb 22, 2021
@chrisboulton
Copy link
Contributor Author

@rboyer - if y'all are open to it, I'd love to find the time to have a chat about an approach here.

I ended up landing on an implementation close to what I describe above, in https://github.com/bigcommerce/consul/compare/0af93a5dfc865dadfb975b58aab2cba775ba64ad..fc270ba01e7457e0721d2951049e8d7790c72b66. I'd love to find a way to get this incorporated into Consul, but I want to make sure it's directionally aligned with the direction HashiCorp wants to go with this kind of thing. I'm happy to just land a pull request and refine from there, if you think that works too.

(We've been in production with this on one of our most heavily trafficked services since the beginning of February, and I consider the changes stable)

@chrisboulton
Copy link
Contributor Author

Actually, I have a pretty good feeling y'all have a handle on this -- I just ran across #9872

@freddygv
Copy link
Contributor

freddygv commented Mar 17, 2021

@chrisboulton Just catching up here. A first pass at it is being released in an experimental alpha likely this week.

Will collect feedback on it over the coming weeks and will have a more finalized design/implementation for the 1.10 beta and GA releases.

@chrisboulton
Copy link
Contributor Author

Sweet - that's great, and I'll keep my eye out for it because we'd love to help kick the tires, given a bunch of these settings are critical for our Consul Connect implementation.

@freddygv
Copy link
Contributor

Hey there, going to close this given that it was released in the 1.10.0-beta1 last week.

Here are the docs:
https://www.consul.io/docs/connect/config-entries/service-defaults#upstream-configuration-beta

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
theme/connect Anything related to Consul Connect, Service Mesh, Side Car Proxies thinking More time is needed to research by the Consul Contributors type/enhancement Proposed improvement or new feature
Projects
None yet
Development

No branches or pull requests

4 participants