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
remove apiserver loopback client QPS limit #80465
remove apiserver loopback client QPS limit #80465
Conversation
Hi @answer1991. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Burst: 100, | ||
Host: "https://" + net.JoinHostPort(host, port), | ||
// Do not limit loopback client QPS. | ||
QPS: -1, |
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.
Why?
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.
@answer1991 Can you explain a bit more here regarding why we shouldn't limit loopback client QPS? Thanks!
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.
Sure.
We found in our API Server lots of goruntine stuck at limiter.Accpet()
and cost lots of time.
API Server will use this client configuration in inner controller, admission client and other client to visit API Server itself. Current configuration will limit the QPS of this client and influence the performance of API Server.
As API Server has already had --max-mutating-requests-inflight
and --max-requests-inflight
to prevent API Server overload from client requests, and API Server use this client in most scenes when client request is accepted. So I think we should remove this client QPS limit to improve API Server throughout capacity.
Any way, to set QPS -1
is tricky, but there is no any other ways to remove the client QPS before we refactor lots of codes.
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.
Related issue: #78766
/cc @aaron-prindle |
/ok-to-test |
pull-kubernetes-node-e2e failure is expected, the job has a known problem with an unavailable image at the moment |
/retest |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: answer1991, lavalamp The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/retest Review the full test history for this PR. Silence the bot with an |
1 similar comment
/retest Review the full test history for this PR. Silence the bot with an |
/retest Review the full test history for this PR. Silence the bot with an |
/retest |
/kind bug |
/test pull-kubernetes-kubemark-e2e-gce-big |
/retest |
@answer1991 Many thanks for sending this PR, apologies that it fell through the cracks until now. |
@lavalamp :-) |
…5-upstream-release-1.13 Automated cherry pick of #80465: remove apiserver loopback client QPS limit
…5-upstream-release-1.15 Automated cherry pick of #80465: remove apiserver loopback client QPS limit
…5-upstream-release-1.16 Automated cherry pick of #80465: remove apiserver loopback client QPS limit
What type of PR is this?
What this PR does / why we need it:
The loopback QPS limit will influence API Server performance, we need to remove limit.
Which issue(s) this PR fixes:
related to #78766
Special notes for your reviewer:
The loopback QPS limit will influence API Server performance, we need to remove limit.
Does this PR introduce a user-facing change?:
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:
None