descheduler when ReplicaSet=1

[jiangxiaobin96]

Is your feature request related to a problem? Please describe.

Deployment often act as backend providing service. If one deployment only has single pod(replicas: 1), descheduler can still evict it. At that time, the service will be stopped while recreating.

Describe the solution you'd like

Add a filter to count the deployments' or jobs' replicas. If replicas=1, this pod can not be evict.

[jiangxiaobin96]

I think this config can be set as parameters associated with each strategy. The implement can refer to RemoveDuplicates where count ownerKeyOccurence

ownerKey := podOwner{
	namespace:  pod.ObjectMeta.Namespace,
	kind:       ownerRef.Kind,
	name:       ownerRef.Name,
	imagesHash: imagesHash,
}
ownerKeyOccurence[ownerKey] = ownerKeyOccurence[ownerKey] + 1

[jiangxiaobin96]

I consider it as a filter minReplicas. Users can set this param like minReplicas:2 means if deployment or job only have less than or equal 2 replications, these pods do not need to evict. Because if there is one or two replications, the service will be stopped or overload when evicting and recreating new pod.

[jiangxiaobin96]

Refer to RemoveDuplicates, we need to calculate owerKey to distinguish different ownerRef pods by unique key Namespace/Kind/Name/imageHash. This ownerRef should be defined as global variable and be used at pkg/descheduler/evictions/evictions.go as a pod filter.

At func (pe *PodEvictor) Evictable() in evictions.go, we can get minReplicas like priority. To each pod, we need to get its replicas according to ownerKeyOccurence and compare it with minReplicas. If pod's replicas less than minReplicas, this pod can not be evict.

[ingvagabund]

This sounds reasonable. This will require to include ReplicaSet/RC/SS informers in the pod evictor to quickly get the number of ready instances. What's the target descheduler version you'd like to have this feature implement?

[rouke-broersma]

Perhaps I'm misunderstanding something but I thought the docs specify that descheduler will never deschedule a single pod?

[damemi]

Perhaps I'm misunderstanding something but I thought the docs specify that descheduler will never deschedule a single pod?

@rouke-broersma could you share which part of the docs makes it sound that way? The descheduler won't evict bare pods (ie, single pods with no replica controller) by default, but that can be overridden

[jiangxiaobin96]

This sounds reasonable. This will require to include ReplicaSet/RC/SS informers in the pod evictor to quickly get the number of ready instances. What's the target descheduler version you'd like to have this feature implement?

I am implementing this function in version v0.23.1.

[rouke-broersma]

@damemi I double checked the docs and could not actually find what I thought I had read. Turns out I misremembered. I think the reason I thought that was because we only enable RemovePodsViolatingInterPodAntiAffinity and RemovePodsViolatingTopologySpreadConstraint which of course don't really apply if you only have 1 replica. Sorry for the confusion.

[jiangxiaobin96]

Is there any examples about one pod containing several ownerReferences?

[jiangxiaobin96]

PodDisruptionBudget is better if deployed in user mode. Close this issue.

[yxiaoy6]

Sorry, I didn't find it in the documentation, I want to confirm, without PodDisruptionBudget, will evict the pod with ReplicaSet=1 in the latest stable version of descheduler?

[jiangxiaobin96]

Without PodDisruptionBudget, descheduler will evict the pod with ReplicaSet=1. ReplicaSet=1 is an example. In some scenes, we must assure there are n% active pods of deployment for serivce. Here, i am in dilemma if there is necessary to add this new filter for descheduler when kebernetes has already supported PodDisruptionBudget.

[yxiaoy6]

PodDisruptionBudget

I think it's necessary, because we won't set PodDisruptionBudget except for stateful services. For clusters that have been in use for a long time, there are already many services, and it is a bit difficult to set PodDisruptionBudget for old services now.

[fanhaouu]

it is necessary to add this new filter for descheduler @jiangxiaobin96

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

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 rotten
• Close this issue 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 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 with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

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

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

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

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

/close not-planned

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.

[a7i]

/open /remove-lifecycle rotten

[k8s-triage-robot]

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

[k8s-triage-robot]

The Kubernetes project currently lacks enough active 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 rotten
• Close this issue 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 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 with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

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

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

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

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

/close not-planned

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.