feat: enable pod protection based on storage classes

[ricardomaraschini]

Description

fixes #633

this commit introduces a new customization on the existing PodsWithPVC
protection. this new customization allow users to make pods that refer
to a given storage class unevictable.

for example, to protect pods referring to storage-class-0 and
storage-class-1 this configuration can be used:

apiVersion: "descheduler/v1alpha2"
kind: "DeschedulerPolicy"
profiles:
- name: ProfileName
  pluginConfig:
  - name: "DefaultEvictor"
    args:
      podProtections:
        extraEnabled:
        - PodsWithPVC
        config:
          PodsWithPVC:
            protectedStorageClasses:
            - name: storage-class-0
            - name: storage-class-1

Changes introduced by this pr:

1. the descheduler starts to observe persistent volume claims.
2. a new api field was introduced to allow per pod protection config.
3. rbac had to be adjusted (+persistentvolumeclaims).

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?

[k8s-ci-robot]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[ricardomaraschini]

/test all

[ricardomaraschini]

/test all

[ricardomaraschini]

/test all

[ricardomaraschini]

/retest

[ricardomaraschini]

/test all

[googs1025]

/ok-to-test

[ricardomaraschini]

/test all

[ricardomaraschini]

/test all

[googs1025]

Can we use noEvictionPolicy directly to solve this issue? 🤔

https://github.com/kubernetes-sigs/descheduler?tab=readme-ov-file#evictor-plugin-configuration-default-evictor

[ricardomaraschini]

Can we use noEvictionPolicy directly to solve this issue? 🤔

https://github.com/kubernetes-sigs/descheduler?tab=readme-ov-file#evictor-plugin-configuration-default-evictor

Would you mind elaborating more ? I did not follow.

[ricardomaraschini]

/test pull-descheduler-test-e2e-k8s-master-1-34

[ricardomaraschini]

@ingvagabund Any other input on this one ?

[ingvagabund]

API nit: storageClasses name does not directly says whether the list of provided SCs will be protected or "every SC but those listed here" will be protected. s/StorageClasses/ProtectedStorageClasses/ will make it more clear.

[ingvagabund]

For future extension it might be better to go with:

StorageClasses []StorageClass

and

type StorageClass struct {
	Name string `json:"name,omitempty`
}

Just in case other SC options become relevant. E.g. protect based on a provisioner rather a specific storage class name.

With the initial validation requiring the name field to be set for each item in StorageClasses list.

[ricardomaraschini]

Those are pretty valid points. I have changed the code accordingly. Please take a look.

[ingvagabund]

/approve
/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ingvagabund

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [ingvagabund]

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