The efficiency of synchronizing Pod status too slow.

kubernetes / kubernetes

Production-Grade Container Scheduling and Management

https://kubernetes.io

Apache License 2.0

108.3k stars 38.86k forks source link

The efficiency of synchronizing Pod status too slow. #123875

Open FengyunPan2 opened 3 months ago

FengyunPan2 commented 3 months ago

What would you like to be added?

Use a single List api instead of multiple Get api.

Why is this needed?

My k8s node is a big machine(500C CPU & 2000GB Memory), the maxPods of kubelet could be set to 200+. When I delete 200+ pods or create 200+ pods, the synchronization of Pod status by the kubelet becomes too slow(about 230s). Making a large number of GET API calls can indeed increase the load on the API server.

k8s-ci-robot commented 3 months ago

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

FengyunPan2 commented 3 months ago

/assign

neolit123 commented 3 months ago

/sig node

ffromani commented 3 months ago

do we have more precise numbers about the (in)efficiency? for example, a graph of pod count vs execution time

matthyx commented 3 months ago

do we have more precise numbers about the (in)efficiency? for example, a graph of pod count vs execution time

I agree with @ffromani it would be nice to see how the new patch improves things.

k8s-triage-robot commented 3 weeks ago

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

After 90d of inactivity, lifecycle/stale is applied
After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

Mark this issue as fresh with /remove-lifecycle stale
Close this issue with /close
Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

vaibhav2107 commented 2 weeks ago

/remove-lifecycle stale