Concurrency issues with the EvictPod method about descheduler

[googs1025]

I think that in a controller pattern, we should use locks to control concurrency.
If necessary, I will submit a pull request to make the modifications. If not needed, I will close this issue.

[damemi]

@googs1025 each plugin is run synchronously, along with each EvictPod request, so I don't think locks are necessary (unless you are referring to some sort of external lock implementation for running multiple descheduler instances?)

Are you currently hitting any concurrency issues with descheduler?

[googs1025]

@googs1025 each plugin is run synchronously, along with each EvictPod request, so I don't think locks are necessary (unless you are referring to some sort of external lock implementation for running multiple descheduler instances?)

Are you currently hitting any concurrency issues with descheduler?

thank you for reply！
No, I was just feeling a bit confused while reviewing the source code. I'm not sure if there is a multi-instance implementation, but typically, if there are multiple instances or concurrency involved, locks or the atomic package are commonly used.
The Evict method in the descheduler also follows the Kubernetes framework, right? If so, it should not involve any concurrency issues.

[damemi]

The Evict method in the descheduler also follows the Kubernetes framework, right? If so, it should not involve any concurrency issues.

Yes, this just calls the kubernetes API so we don't need to worry about concurrency there

[googs1025]

ok, I'll closed this issue.

[googs1025]

/close

[k8s-ci-robot]

@googs1025: Closing this issue.

In response to this:

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.