Skip to content
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.

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

Concurrency issues with the EvictPod method #1388

Closed
googs1025 opened this issue May 2, 2024 · 7 comments
Closed

Concurrency issues with the EvictPod method #1388

googs1025 opened this issue May 2, 2024 · 7 comments

Comments

@googs1025
Copy link
Member

googs1025 commented May 2, 2024

Does EvictPod need to be locked to control concurrency?

https://github.com/kubernetes-sigs/descheduler/blob/master/pkg/descheduler/evictions/evictions.go#L157

// pkg/descheduler/evictions/evictions.go
// EvictPod evicts a pod while exercising eviction limits.
// Returns true when the pod is evicted on the server side.
func (pe *PodEvictor) EvictPod(ctx context.Context, pod *v1.Pod, opts EvictOptions) bool {
	var span trace.Span
	ctx, span = tracing.Tracer().Start(ctx, "EvictPod", trace.WithAttributes(attribute.String("podName", pod.Name), attribute.String("podNamespace", pod.Namespace), attribute.String("reason", opts.Reason), attribute.String("operation", tracing.EvictOperation)))
	defer span.End()
	...
        // Is there a need to lock here?
	if pod.Spec.NodeName != "" {
		pe.nodepodCount[pod.Spec.NodeName]++
	}
	pe.namespacePodCount[pod.Namespace]++

	if pe.metricsEnabled {
		metrics.PodsEvicted.With(map[string]string{"result": "success", "strategy": opts.StrategyName, "namespace": pod.Namespace, "node": pod.Spec.NodeName, "profile": opts.ProfileName}).Inc()
	}

	...
	return true
}
@googs1025 googs1025 changed the title Does EvictPod need to be locked to control concurrency? Concurrency issues with the EvictPod method May 2, 2024
@googs1025
Copy link
Member Author

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
Copy link
Contributor

damemi commented May 2, 2024

@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
Copy link
Member Author

googs1025 commented May 2, 2024

@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
Copy link
Contributor

damemi commented May 2, 2024

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
Copy link
Member Author

ok, I'll closed this issue.

@googs1025
Copy link
Member Author

/close

@k8s-ci-robot
Copy link
Contributor

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants