[kube-prometheus-stack] remove support for deprecated apis

[DrFaust92]

What this PR does / why we need it

Which issue this PR fixes

(optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged)

• relates [All] Drop support for non current Kuberentes versions #5671

Special notes for your reviewer

Checklist

• DCO signed
• Chart Version bumped
• Title of the PR starts with chart name (e.g. [prometheus-couchdb-exporter])

[jkroepke]

What about

• PodDisruptionBudget
• NetworkPolicy

and even drop PSP as well?

@QuentinBisson @GMartinez-Sisti What your opinion here?

I'm also thinking about an major version bump here.

@schnatterer fyi - since you worked with old versions as I can remember.

[QuentinBisson]

I agree that we need a major and removing the others would make sense yes.

[schnatterer]

@jkroepke Thanks for looping me in! Fortunately, legacy K8s version were not my problem. Only legacy PromStack CRDs on relatively recent k8s versions (1.25+) 😅

[DrFaust92]

What about

• PodDisruptionBudget
• NetworkPolicy

and even drop PSP as well?

@QuentinBisson @GMartinez-Sisti What your opinion here?

I'm also thinking about an major version bump here.

@schnatterer fyi - since you worked with old versions as I can remember.

I thought of doing it in subsequent PRs but sure I can do it all in one

[jkroepke]

Just would like to know which features requires Kubernetes 1.25?

[DrFaust92]

Just would like to know which features requires Kubernetes 1.25?

https://kubernetes.io/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/ removal of PSP

[jkroepke]

But does it make sense to require a version of Kubernetes, which just removed a API? To my best knowledge, even with the removal of all legacy APIs. PSP was always optional and I do not see a problem to install that chart on Kubernetes 1.20?

[QuentinBisson]

Do you think it makes sense that we maintain that compatibility even just in name when we do not even test that it works?
I also think it makes sense that we push users to upgrade because no one should bé running 1.19 anymore

[jkroepke]

Do you think it makes sense that we maintain that compatibility even just in name when we do not even test that it works?

No, not maintain the compatibility on older version. But with kubeVersion, we actively deny the installation on older version.

I feel there is no reason to actively deny the installation on older cluster, even we are not supporting it.

I would remove the kubeVersion from the chart yaml and would add supporting section in the README.md that we only support the latest 5 versions.

Latest 5 may seems over extendend, but kube-prometheus-stack is just pod, deployments, pvc.. nothing really special and Kubernetes seems stable here.

[QuentinBisson]

It is, as long as the prometheus operator does not start to rely on CEL :D

[QuentinBisson]

I'm not specifically against your change either, it just felt proper when reviewing