-
Notifications
You must be signed in to change notification settings - Fork 329
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
capacity: use separate client and lower QPS/Burst settings #711
capacity: use separate client and lower QPS/Burst settings #711
Conversation
The rationale behind this change is that it allows external-provisioner to deal with volumes without being slowed down by the concurrent CSIStorageCapacity updates. Those updates are less important and the scheduler can deal with outdated information, so enforcing a lower rate by default is acceptable. If few changes are needed, updating CSIStorageCapacity keeps up with volume changes. If many volumes get created or deleted quickly, throttling the updating is beneficial because multiple changes can be combined into a single update. This has helped in practice during a scale test with 100 nodes and 10000 pods+volumes. Without this change, there were intermittent problems with an unresponsive apiserver. With this change, no such problems occurred.
/hold I'm currently rerunning the scale test, let's wait with merging until that is completed. |
/hold cancel The test completed two more times with this change. |
/lgtm |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jsafrane, pohly 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 |
What type of PR is this?
/kind feature
What this PR does / why we need it:
The rationale behind this change is that it allows external-provisioner to deal
with volumes without being slowed down by the concurrent CSIStorageCapacity
updates. Those updates are less important and the scheduler can deal with
outdated information, so enforcing a lower rate by default is acceptable.
If few changes are needed, updating CSIStorageCapacity keeps up with volume
changes. If many volumes get created or deleted quickly, throttling the
updating is beneficial because multiple changes can be combined into a single
update.
This has helped in practice during a scale test with 100 nodes and 10000
pods+volumes. Without this change, there were intermittent problems with an
unresponsive apiserver. With this change, no such problems occurred.
Special notes for your reviewer:
Does this PR introduce a user-facing change?: