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

Limit concurrent route creations #26263

Merged
merged 1 commit into from May 26, 2016

Conversation

wojtek-t
Copy link
Member

@wojtek-t wojtek-t commented May 25, 2016

Ref #26119

This is supposed to improve 2 things:

  • retry creating route in routecontroller in case of failure
  • limit number of concurrent CreateRoute calls in flight.

We need something like that, because we have a limit of concurrent in-flight CreateRoute requests in GCE.

@gmarek @cjcullen

@wojtek-t wojtek-t added the release-note-none Denotes a PR that doesn't merit a release note. label May 25, 2016
@wojtek-t wojtek-t added this to the v1.3 milestone May 25, 2016
@k8s-github-robot k8s-github-robot added the size/M Denotes a PR that changes 30-99 lines, ignoring generated files. label May 25, 2016
@wojtek-t wojtek-t changed the title Spread creating routes over time and retry on failures Limit concurrent route creations May 25, 2016
@wojtek-t wojtek-t force-pushed the fix_route_controller branch 3 times, most recently from ff27949 to 80a29ba Compare May 25, 2016 14:11
@k8s-github-robot k8s-github-robot added size/S Denotes a PR that changes 10-29 lines, ignoring generated files. and removed size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels May 25, 2016
// that means that we may wait up to 5 minutes before even starting
// creating a route for it. This is bad.
// We should have a watch on node and if we observe a new node (with CIDR?)
// trigger reconciliation for that node.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an extant issue, but #26267 will at least cause it to be NotReady until the route is programmed, right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes - this is a long standing issue (it's nothing new). I will send a PR for it, but that won't be trivial change, so I'm not sure if it will land in 1.3.
But yeah - #26267 would makes nodes to be not ready in such case.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would file an issue and we can triage it. If it's long standing, nothing huge to worry about. One thing is that "new node" in the large cluster sense is kind of gradual, though - basically everything in the first half hour looks like a new node, so that resync period could be a little relevant. One question I had is whether the reconcile loop works like { reconcile(); sleep(constant); } or if it's { reconcile(); sleep( to-meet-five-minutes ). (Was a question I keep meaning to answer.)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Huh. Unless I'm misreading JitterUntil badly, it's the former and not the latter.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the former. i can file an issue but it's hard with kid on hands :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually - he is eating now.
#26274 filed for this.

@zmerlynn
Copy link
Member

Some medium level nits, otherwise LGTM. If you're back online tonight, we can iterate on this in realtime and get it done. I'm testing it now, but I think it might actually be best accompanied by a revert of #26140 (which you could do by just pushing a git revert 55fdc1c036df7fa2b22cd475aa597990c6e29491 && git revert 9b5cdfb705a9ed53f5bb376133a17e6b5c051311 onto this PR). I think we're unnecessarily throttling the non-operation-GETs, and it may be slowing down other things - my PR was headed toward fixing that, but just taking the limiters off could be faster / could work. I'm about to test that now.

@k8s-github-robot k8s-github-robot added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. and removed size/S Denotes a PR that changes 10-29 lines, ignoring generated files. labels May 25, 2016
@wojtek-t
Copy link
Member Author

PTAL

@wojtek-t
Copy link
Member Author

@zmerlynn - to be honest, I wouldn't revert that PR, because there is also another qps limit on all api calls. so I think both are necessary. Though we may want to bump the limit from 10 to sth like 19. or 20. WDYT?

@zmerlynn
Copy link
Member

zmerlynn commented May 25, 2016

With this and the two reverts suggested, 1k nodes seems pretty happy, though route programming is still taking quite a long time.

@wojtek-t: My concern on the rate limiting is that we're now de-prioritizing GETs (like instance gets/lists) behind things like operations polls, or even the bulk insertion of routes when the 200 kicked. Just looking at the logs, we were delayed by upwards of 20s sometimes, even with the QPS in master (i.e. I wasn't running with my PR). I suppose bumping it to 19 could work, but the "more right" answer is something like a hierarchical token bucket where the operation-polls can get pushed out almost completely.

@wojtek-t
Copy link
Member Author

@wojtek-t: My concern on the rate limiting is that we're now de-prioritizing GETs (like instance gets/lists) behind things like operations polls, or even the bulk insertion of routes when the 200 kicked. Just looking at the logs, we were delayed by upwards of 20s sometimes, even with the QPS in master (i.e. I wasn't running with my PR). I suppose bumping it to 19 could work, but the "more right" answer is something like a hierarchical token bucket where the operation-polls can get pushed out almost completely

I though that 20QPS limit includes operation GETs. Isn't it the case?

startTime := time.Now()
// Ensure that we don't have more than maxConcurrentRouteCreations
// CreateRoute calls in flight.
rateLimiter <- struct{}{}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can add the additional logging here after we get it in, it's not a big deal. This looks fine.

@zmerlynn zmerlynn added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label May 25, 2016
@zmerlynn
Copy link
Member

@k8s-oncall: Manual merge please, if we ever get a passing result.

@k8s-github-robot
Copy link

@zmerlynn
You must link to the test flake issue which caused you to request this manual re-test.
Re-test requests should be in the form of: k8s-bot test this issue: #<number>
Here is the list of open test flakes.

@k8s-github-robot k8s-github-robot removed the lgtm "Looks good to me", indicates that a PR is ready to be merged. label May 25, 2016
@zmerlynn zmerlynn added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label May 25, 2016
@zmerlynn
Copy link
Member

@k8s-bot test this, issue #IGNORE (fighting PR builder)

@zmerlynn zmerlynn added priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. and removed priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. labels May 25, 2016
k8s-github-robot pushed a commit that referenced this pull request May 26, 2016
Automatic merge from submit-queue

GCE provider: Revert rate limits

[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/.github/PULL_REQUEST_TEMPLATE.md?pixel)]() This reverts #26140 and #26170. After testing with #26263, #26140 is unnecessary, and we need to be able to prioritize normal GET / POST requests over operation polling requests, which is what the pre-#26140 requests do.

c.f. #26119
@wojtek-t wojtek-t added priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. priority/backlog Higher priority than priority/awaiting-more-evidence. and removed priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. labels May 26, 2016
@k8s-github-robot k8s-github-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label May 26, 2016
@wojtek-t
Copy link
Member Author

Trivial rebase - reapplying lgtm.

@wojtek-t wojtek-t added lgtm "Looks good to me", indicates that a PR is ready to be merged. and removed lgtm "Looks good to me", indicates that a PR is ready to be merged. labels May 26, 2016
@k8s-github-robot k8s-github-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label May 26, 2016
@k8s-github-robot
Copy link

@k8s-bot test this [submit-queue is verifying that this PR is safe to merge]

@k8s-bot
Copy link

k8s-bot commented May 26, 2016

GCE e2e build/test passed for commit aa65a79.

@k8s-github-robot
Copy link

Automatic merge from submit-queue

@k8s-github-robot k8s-github-robot merged commit d3d6185 into kubernetes:master May 26, 2016
@wojtek-t wojtek-t deleted the fix_route_controller branch June 15, 2016 14:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lgtm "Looks good to me", indicates that a PR is ready to be merged. priority/backlog Higher priority than priority/awaiting-more-evidence. release-note-none Denotes a PR that doesn't merit a release note. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants