Clarify descheduler handling of StatefulSets

[lindhe]

It's clear to me from the documentation that "Pods with local storage are never evicted (unless evictLocalStoragePods: true is set)", which makes sense since that indicates that the application is stateful and thus cannot be restarted as surely as a stateful app would. I would assume the same logic holds for pods in StatefulSets, but I find no documentation about that.

If my assumption is correct:

• we should add that to the documentation.

If my assumption is incorrect:

• let's clarify that in the documentation.
• I suggest we reconsider that design choice.

If I'm missing something here, please fill me in.

[seanmalloy]

Based on the below code block I believe that the descheduler will consider StatefulSets for eviction.

descheduler/pkg/descheduler/evictions/evictions.go

Lines 218 to 249 in 6abfa23

	// IsEvictable decides when a pod is evictable
	func (ev *evictable) IsEvictable(pod *v1.Pod) bool {
	checkErrs := []error{}
	if IsCriticalPod(pod) {
	checkErrs = append(checkErrs, fmt.Errorf("pod is critical"))
	}
	ownerRefList := podutil.OwnerRef(pod)
	if IsDaemonsetPod(ownerRefList) {
	checkErrs = append(checkErrs, fmt.Errorf("pod is a DaemonSet pod"))
	}
	if len(ownerRefList) == 0 {
	checkErrs = append(checkErrs, fmt.Errorf("pod does not have any ownerrefs"))
	}
	if IsMirrorPod(pod) {
	checkErrs = append(checkErrs, fmt.Errorf("pod is a mirror pod"))
	}
	for _, c := range ev.constraints {
	if err := c(pod); err != nil {
	checkErrs = append(checkErrs, err)
	}
	}
	if len(checkErrs) > 0 && !HaveEvictAnnotation(pod) {
	klog.V(4).InfoS("Pod lacks an eviction annotation and fails the following checks", "pod", klog.KObj(pod), "checks", errors.NewAggregate(checkErrs).Error())
	return false
	}
	return true
	}

If I'm correct then the docs here just need to be updated to indicate that StatefulSet pods are considered for eviction in addition to RC, RS, Deployment and Job.

If the ask is to add a feature to have an option to include/exclude StatefulSet pods then this would be a feature enhancement request. Keep in mind there are already many other ways to have the descheduler include/exclude pods.

https://github.com/kubernetes-sigs/descheduler#filter-pods

Also, starting with the upcoming descheduler v0.21.0 release there will be an ignorePvcPods option in addition to the currentevictLocalStoragePods option.

[seanmalloy]

I created PR #520 to document the current behavior.

@lindhe is updating the documentation good enough to close this issue or do you want to discuss a feature for excluding StatefulSets further?

From my perspective I think the descheduler has enough options to choose which pods are considered or not considered for eviction, but we welcome feedback if the current functionality does not fit your needs.

[lindhe]

Cool, thanks a lot for the PR! Having it documented properly was the most important part in my view. I may continue the discussion to understand better why sts by their nature are not excluded, but if I continue that thread it can surely be done without this Issue open.

Let's mark this as closed when the PR is merged.

[seanmalloy]

/assign

[seanmalloy]

/kind documentation

[seanmalloy]

Tasks to complete before closing this issue:

• documentation
• unit tests
• e2e tests

[ingvagabund]

@seanmalloy do you still want to implement e2e for this?

[seanmalloy]

@seanmalloy do you still want to implement e2e for this?

@ingvagabund yes I was going to wait until #535 is merged.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[ingvagabund]

@seanmalloy The PR is merged
/remove-lifecycle stale

[seanmalloy]

FYI ... I'm still going to submit a PR to implement the e2e tests. I had to take a break for a bit.

[k8s-triage-robot]

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

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[pravarag]

/remove-lifecycle stale

[k8s-triage-robot]

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

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[k8s-triage-robot]

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

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle rotten

[k8s-triage-robot]

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

This bot triages issues and PRs 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:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

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

This bot triages issues and PRs 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:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

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