Skip to content

Add jittering for Kubelet status computing #105272

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.

Sign up for GitHub

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

Merged
k8s-ci-robot merged 1 commit into from
Sep 28, 2021
Merged

Add jittering for Kubelet status computing #105272

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 4 additions & 2 deletions pkg/kubelet/kubelet.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1468,8 +1468,10 @@ func (kl *Kubelet) Run(updates <-chan kubetypes.PodUpdate) {
go kl.volumeManager.Run(kl.sourcesReady, wait.NeverStop)

if kl.kubeClient != nil {
// Start syncing node status immediately, this may set up things the runtime needs to run.

@SergeyKanzhelev SergeyKanzhelev Sep 27, 2021

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

for the context on this comment: #14542 (comment)

go wait.Until(kl.syncNodeStatus, kl.nodeStatusUpdateFrequency, wait.NeverStop)
// Introduce some small jittering to ensure that over time the requests won't start
// accumulating at approximately the same time from the set of nodes due to priority and
// fairness effect.
go wait.JitterUntil(kl.syncNodeStatus, kl.nodeStatusUpdateFrequency, 0.04, true, wait.NeverStop)

@wojtek-t wojtek-t Sep 27, 2021

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

To follow up on the 0.04 vs 0.1:

  • withe default 10s statusUpdateFrequency, 0.1 means 1s, so we would be calculating every 9s-11s. That sounded acceptable to me.
  • that said with 0.04 (so 9.6s-10.4s with default frequency) - we seem to be getting good enough spread over time for extended periods of time.
    So I'm completely fine with setting it to 0.04 for consistency. If at some point we realize we need more - we can revisit it, but it doesn't seem to be the case now.

go kl.fastStatusUpdateOnce()

// start syncing lease
Expand Down