Should KEDA enforce Kubernetes version through Helm?

[tomkerkhove]

KEDA only supports a subset of Kubernetes versions and we've heard some feedback on why Helm enforces this?

The current thinking is that we help you run on supported versions and use that as a warning. If you know what you are doing, you can by pass this but then you know you are running an unsupported Kubernetes version.

Let's hear from the community what people think

[tomkerkhove]

My worry is that if we don't do it, chances are that:

• End-users run on old Kubernetes versions that we don't support (anymore) after doing upgrades
• We get support questions for things we don't support, which increases load on maintainers

[JorTurFer]

We are already requesting k8s versions for the issues, and I think that users will open issues exactly the same but changing the topic from "KEDA doesn't work in k8s vStone" to "Helm chart fails in k8s vStone", but they will open the issue (IMO).

Apart from the thing above, my concern is: If we do that in helm, let’s do it also in the code, if you want to execute KEDA outside supported versions, you can add an env accepting it.
I mean, users could just bump the image version (as they do with helm chart version, same effort) and in that case, we will be in the same scenario. Should we introduce a check in the code to request an ENV or an argument to guarantee that they know what they're doing?

I agree with our support policy, but I think that running outside supported versions is responsibility of the users, and we can just close the issues saying that it's unsupported (and maybe a link to the support policy)

[tomkerkhove]

I think there is a difference in enforcing in the KEDA runtime vs the deployment artifact that it offers.

I do agree on enforcing on Helm, but not on runtime. If somebody else upgrades the Kubernetes version without KEDA, the runtim will keep on running but you won't be able to do upgrades. You don't want your autoscaler, however, to stop working because of that.

[pragmaticivan]

Keda and helm Chart could have the same enforcement to avoid side effects.

Right now, Keda itself only requires a minimum of 1.23 in its latest version, but the chart enforces 1.24 as minimum version.

I probably have an edge case because I follow a different calendar (AWS EKS EOL).

[tomkerkhove]

Agreed!

Right now, Keda itself only requires a minimum of 1.23 in its latest version, but the chart enforces 1.24 as minimum version.

However, this is not correct:

https://keda.sh/docs/2.10/operate/cluster/

[pragmaticivan]

In this page, yes. In the changelog there's only one entry talking about requirement https://github.com/kedacore/keda/blob/main/CHANGELOG.md#v290 under 2.9. So unless I'm missing something, Keda 2.10 will actually work with v1.23 because it's not using any new API? I might just be missing something, so you are probably 100% right

[zroubalik]

Working != community supported & tested. That's the problem we need to solve.

My vote would be to remove any artificial restrictions, let people run it on whatever platform they want to, we should just clearly mention the "support" (thout it is not a real support anyway 😄 ).

[tomkerkhove]

I'm not a fan of that as end-users might not be aware of it, but looks like I'm alone on this so we can remove the Kubernetes restrictions and add something to the output saying it's a supported or unsupported version in NOTES.txt.

Would that suffice?

[tomkerkhove]

If you remove restriction, please make sure there is a warning in the notes @zroubalik .

[pragmaticivan]

Not sure if that's extremely reliable, but maybe we can maintain a github workflow with kubepug

kubepug --k8s-version v1.23.0 --input-file=manifest.yaml
RESULTS:
Deprecated APIs:


Deleted APIs:

[JorTurFer]

What for? I mean, during the release process, we already know the supported versions and they are documented. Although KEDA can run in other versions, we still limit the support to N-2, otherwise the amount of version would be terrible

[pragmaticivan]

All good, just informative metadata so people are aware. Something along the lines, we only support N-2, but this tool might help guide folks who want to take the risk. I guess they actually should be the ones running that tool after so, probably not a good one to add to the project.

[JorTurFer]

Personally, I wouldn't do anymore related with this because it's totally in the end users side, even if the tool says that it's compatible, we won't give any kind of support for it. But let's see other thoughts 😄