Add configurable Kubernetes API client QPS and burst rate limits#1281
Merged
Conversation
The Kubernetes API client created via rest.InClusterConfig() uses client-go defaults of QPS=5 and Burst=10. When WORKERS is set to 50 or higher for correlated spot interruption scenarios, all workers share this single rate limiter, causing severe client-side throttling (8-10 second waits per API call). Add KUBE_API_QPS and KUBE_API_BURST environment variables (and corresponding CLI flags) to allow configuring the client rate limits. Defaults preserve backward compatibility (QPS=5, Burst=10). Testing with 50 concurrent spot interruptions shows: - Default QPS=5: 78% taint success, 154s P99 cordon latency - QPS=100, Burst=200: 100% taint success, 52s P99 cordon latency Fixes: aws#1280 Signed-off-by: Marius Cornea <mcornea@redhat.com>
|
This PR has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want this PR to never become stale, please ask a maintainer to apply the "stalebot-ignore" label. |
|
This PR was closed because it has become stale with no activity. |
Lu-David
approved these changes
Jul 21, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description of changes
Add
KUBE_API_QPSandKUBE_API_BURSTenvironment variables (and corresponding--kube-api-qps/--kube-api-burstCLI flags) to configure the Kubernetes API client rate limits.The client created via
rest.InClusterConfig()uses client-go defaults of QPS=5 and Burst=10. WhenWORKERSis set to 50 or higher for correlated spot interruption scenarios, all workers share this single rate limiter, causing severe client-side throttling (8-10 second waits per API call). This prevents NTH from processing all interruption events within the 2-minute AWS spot interruption notice window.Changes:
pkg/config/config.go: AddKUBE_API_QPS(default 5) andKUBE_API_BURST(default 10) configuration parameterscmd/node-termination-handler.go: Apply QPS/Burst torest.Configbefore creating the clientsetDefaults preserve backward compatibility.
Fixes: #1280
How you tested your changes
Environment (Linux): ROSA HCP on AWS (us-east-2), 50 spot nodes (c5a.xlarge, 3 AZs)
Kubernetes Version: v1.35.5 (OpenShift 4.22)
Triggered 50 concurrent spot interruptions via AWS FIS (
aws:ec2:send-spot-instance-interruptionswithdurationBeforeInterruption=PT2M):WORKERS=50, QPS=5 (default)WORKERS=50, QPS=100, Burst=200NTH logs with default QPS show continuous client-side throttling:
With QPS=100, zero throttling events and all 50 nodes processed within the 2-minute window.