Added new policy of maxodpernode

[Deep28032001]

Description

This PR introduces the MaxPodsPerNode descheduling strategy.

Summary of Changes:
New Plugin: Implemented the MaxPodsPerNode plugin under the descheduler/evictions framework.
Logic: The plugin identifies nodes exceeding a user-defined MaxPods threshold and evicts the most recently created pods (LIFO approach) until the node is within the limit.
Filtering: Supports standard descheduler filters, including namespace inclusion/exclusion and label selectors.
Sorting: Implements custom sorting using pods[j].CreationTimestamp.Before(&pods[i].CreationTimestamp) to ensure stability during rescheduling loops.

Motivation:
Currently, clusters can become unbalanced where specific nodes host a disproportionate number of pods, leading to resource contention or blast-radius concerns. This strategy provides a simple, count-based guardrail to trigger pod redistribution.

Checklist

Please ensure your pull request meets the following criteria before submitting
for review, these items will be used by reviewers to assess the quality and
completeness of your changes:

• Code Readability: Is the code easy to understand, well-structured, and consistent with project conventions?
• Naming Conventions: Are variable, function, and structs descriptive and consistent?
• Code Duplication: Is there any repeated code that should be refactored?
• Function/Method Size: Are functions/methods short and focused on a single task?
• Comments & Documentation: Are comments clear, useful, and not excessive? Were comments updated where necessary?
• Error Handling: Are errors handled appropriately ?
• Testing: Are there sufficient unit/integration tests?
• Performance: Are there any obvious performance issues or unnecessary computations?
• Dependencies: Are new dependencies justified ?
• Logging & Monitoring: Is logging used appropriately (not too verbose, not too silent)?
• Backward Compatibility: Does this change break any existing functionality or APIs?
• Resource Management: Are resources (files, connections, memory) managed and released properly?
• PR Description: Is the PR description clear, providing enough context and explaining the motivation for the change?
• Documentation & Changelog: Are README and docs updated if necessary?

[linux-foundation-easycla]

• ❌ The email address for the commit (4929eb8) is not linked to the GitHub account, preventing the EasyCLA check. Consult this Help Article and GitHub Help to resolve. (To view the commit's email address, add .patch at the end of this PR page's URL.) For further assistance with EasyCLA, please submit a support request ticket.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign a7i for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

Welcome @Deep28032001!

It looks like this is your first PR to kubernetes-sigs/descheduler 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/descheduler has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @Deep28032001. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

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-sigs/prow repository.

[ingvagabund]

@Deep28032001 thank you for your contribution. Can you please more elaborate on benefits of the new plugin compared to the existing node utilization plugins? I.e. they already provide means to balance pods among nodes based on the resource utilization. There's pods resource that can be set to the max number of pods (in %) per node. You can check the example under https://github.com/kubernetes-sigs/descheduler#lownodeutilization.