Optimize your clusters with the Descheduler for Kubernetes

Sometimes, it’s hard to maintain an efficient Kubernetes cluster. Trying to organize things through scheduling is possible, but sometimes nodes or pods fall through the cracks or fail. After all, the scheduler’s decisions are made based on priorities when a new pod appears for scheduling. But since Kubernetes is dynamic by design, these decisions might not be optimal later on.

What then? kube-scheduler isn’t designed to move or evict nodes, even if they are over/under-utilized or the node itself has failed. Enter the Descheduler for Kubernetes. Descheduler for Kubernetes finds pods that can be moved and evicts them. It doesn’t schedule replacements for the evicted nodes (yet), just tides up nodes.

Descheduler’s policy is highly configurable and comes with a number of different strategies that developers can choose to enable or disable. Right now, Descheduler comes with four different strategies automatically enabled:

• RemoveDuplicates – No multiples here! Using this makes sure that there is only one pod associated with a Replica Set (RS), Replication Controller (RC), Deployment, or Job on same node. Any copycat pods are evicted so there is a better spread of pods in a cluster.
• LowNodeUtilization – Aiming for optimized performance, this option finds underutilized nodes and evicts pods from other highly utilized pods to see if they’ll be moved to a more optimal spot. Developers can configure their threshold for what qualifies as underutilized based on CPU, memory, and percentage.
• RemovePodsViolatingInterPodAntiAffinity – Any pods violating interpod anti-affinity are removed from nodes.
• RemovePodsViolatingNodeAffinity – Any pods violating node affinity are removed from nodes.

SEE ALSO: Kubernetes adoption hasn’t exploded yet, new study shows

Descheduler can be run as a job inside of a pod multiple times without user intervention.

When Descheduler decides to evict pods from a node, it does have to follow a general set of rules. Critical pods are never evicted. Standalone pods can’t be evicted either; pods have to be associated with a RC, RS, Deployment, or Job in order to be evicted. Pods associated with DaemonSets or local storage are also safe. And best effort pods are evicted before Burstable and Guaranteed pods.

Get the Descheduler for Kubernetes

As you might have guessed, Descheduler is openly available on GitHub for anyone to use. Kubernetes version 1.9 and above is recommended for the newest version of the Descheduler.

Like many other Kubernetes projects, it is supported by community interest. So, feedback and any input is welcome!ing

The post Optimize your clusters with the Descheduler for Kubernetes appeared first on JAXenter.