Skip to content

set k8s registry QPS to match MAX_PODS#1801

Open
msporleder-work wants to merge 1 commit intoawslabs:mainfrom
msporleder-work:main
Open

set k8s registry QPS to match MAX_PODS#1801
msporleder-work wants to merge 1 commit intoawslabs:mainfrom
msporleder-work:main

Conversation

@msporleder-work
Copy link
Copy Markdown

Issue #, if available:

Description of changes:

When nodes failover in EKS, regardless of their size, the default RegistryPullQPS of 5 highly limits their ability to startup cleanly when running a cluster with more than a few pods.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Testing Done

node failovers/drains on my clusters constantly fail. Bumping the QPS with user-data solves it but this, I think, is a better default.

See this guide for recommended testing for PRs. Some tests may not apply. Completing tests and providing additional validation steps are not required, but it is recommended and may reduce review time and time to merge.

if [[ "$USE_MAX_PODS" = "true" ]]; then
echo "$(jq ".maxPods=$MAX_PODS" $KUBELET_CONFIG)" > $KUBELET_CONFIG
#set registryPullQPS to match MAX_PODS to prevent startup problems when nodes failover
echo "$(jq --arg MAX_PODS $MAX_PODS '.+= {"registryPullQPS":$MAX_PODS}' $KUBELET_CONFIG)" > $KUBELET_CONFIG
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I think it makes sense to increase this beyond 5; but I don't think we want to go all the way to MAX_PODS -- that's a very large value on many instance types. Have you tested a more moderate increase, something like 10+15burst (up from 5+10burst)?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

I actually just set it to 0 (disabled). containerd times out commonly for me starting up 50-ish pods at once so I've also started to bump runtimeRequestTimeout.

I definitely think this number should be dynamic and I was suggesting max_pods as a proxy since, if a pod is "full" and it fails, the next one to boot up will potentially get all of those pods assigned.

@github-actions
Copy link
Copy Markdown
Contributor

This pull request is stale because it has been open for 60 days with no activity. Remove the stale label or comment to avoid closure in 14 days

@github-actions github-actions bot added the Stale label Nov 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants