chore(argo-cd): Upgrade supported Kubernetes version to v1.23.0

[yu-croco]

EKS v1.22 is over the EoL, so let's move on.

https://endoflife.date/amazon-eks

---

Checklist:

• I have bumped the chart version according to versioning
• I have updated the documentation according to documentation
• I have updated the chart changelog with all the changes that come with this pull request according to changelog.
• Any new values are backwards compatible and/or have sensible default.
• I have signed off all my commits as required by DCO.
• My build is green (troubleshooting builds).

[mbevc1]

Is this a typo and should it be >=1.23.0-0 instead of both. Reads a bit confusing now 🤔

[yu-croco]

Thank you for reviewing. Ah... now I realize it's so confusing..

Below would be simpler...? 🙋

- This version supports Kubernetes version from `>=1.22.0-0` to `>=1.23.0-0`.
+ This version supports Kubernetes version `>=1.23.0-0`.

[tico24]

Apologies for missing this on the review. My brain filled in the words instead of reading them :)

[yu-croco]

I fixed at 2b2e351 🙋

[mbevc1]

How about something like this?

Suggested change

	This version supports Kubernetes version `>=1.23.0-0`. Though the supported version of Kubernetes is v1.24 or later, we align with Amazon EKS because there are a lot of EKS users.
	This version supports Kubernetes version `>=1.23.0-0`. The current supported version of Kubernetes is v1.24 or later and we align with Amazon EKS calendar, because many of AWS users and conservative approach.

[mbevc1]

How about something like this?

Suggested change

	This version supports Kubernetes version `>=1.23.0-0`. Though the supported version of Kubernetes is v1.24 or later, we align with Amazon EKS because there are a lot of EKS users.
	This version supports Kubernetes version `>=1.23.0-0`. The current supported version of Kubernetes is v1.24 or later and we align with Amazon EKS calendar, because many of AWS users and conservative approach.

[mbevc1]

Thanks, looks better. I've left a potential improvement. But it's not a blocker.

[yu-croco]

@mbevc1
Thank you !
I fixed at 724e891 . 😄

[mbevc1]

Thanks 👍

[agaudreault]

This is kind of annoying to have that configuration in the chart. IMO, the kubeVersion defined in this chart should not be coupled to EKS release cycle. Not all users of this chart use EKS. The value should represent the minimum value of the cluster on which it can be installed on, like specified in the Helm doc. If it works on 1.22 and all resources are supported, why make it unusable?

Because of this change, users deploying argo on older versions of Kubernetes will need to fork the chart to have fixes and improvements.

[mkilchhofer]

Do you know the support matrix of Argo CD?
While the newest version mostly works also with very old kubernetes versions, it is simply not tested by the upstream project.
The upstream project supports only the 3 recent minor versions of kubernetes.

Refs:

• Explicitly document the Kubernetes version compatibility for each ArgoCD release in a single location argo-cd#12276
• https://argo-cd.readthedocs.io/en/stable/operator-manual/installation/#supported-versions

[yu-croco]

In addition to @mkilchhofer 's opinion, the kubeVersion itself covers more than Kubernetes's EoL. So I think this change was conservative enough.
https://endoflife.date/kubernetes

Also other cloud services' K8s are also covered.

• https://endoflife.date/google-kubernetes-engine
• https://endoflife.date/azure-kubernetes-service

[agaudreault]

The upstream project supports only the 3 recent minor versions of kubernetes.

While the container image may or may not work with some versions of Kubernetes, this is not the same as the compatibility of a Helm chart. Both do not need to be coupled. The chart can be used with an older version of ArgoCD by overriding the tag.

The kubeVersion field in a chart is a hard limit and should only be set if the chart resources aren't compatible with older Kubernetes versions or container image. AFAIK this chart works fine with older Kubernetes versions, assuming that the image tag is changed to use a suitable ArgoCD image version.

My suggestion would be to remove kubeVersion and update the README with a compatibility table instead of setting a hard limit.

The only limitation I can see is that 5.31.0 must be used with ArgoCD >= 2.7.0. And while ArgoCD is tested up to the N-1 release of k8s, it does not mean that it does not work on earlier version than that. So this chart should not hinder the users to install it on older clusters.

Another advantage to have a compatibility matrix is the ability to update it when problems are discovered after the release. Usage of kubeVersion cannot be reverted unless overriding the chart version.