Review supported versions of K8S for 2.0.0 release

[manics]

Proposed change

Currently we test and support K8s versions 1.17 to 1.23:

zero-to-jupyterhub-k8s/.github/workflows/test-chart.yaml

Lines 127 to 154 in 6f4609e

	- k3s-channel: v1.23
	test: install
	debuggable: debuggable
	- k3s-channel: v1.22
	test: install
	- k3s-channel: v1.21
	test: install
	- k3s-channel: v1.20
	test: install
	- k3s-channel: v1.19
	test: install
	- k3s-channel: v1.18 # also test prePuller.hook
	test: install
	local-chart-extra-args: >-
	--set prePuller.hook.enabled=true
	--set prePuller.hook.pullOnlyOnChanges=true
	- k3s-channel: v1.17 # also test hub.existingSecret
	test: install
	local-chart-extra-args: >-
	--set hub.existingSecret=test-hub-existing-secret
	--set proxy.secretToken=aaaa1111
	--set hub.cookieSecret=bbbb2222
	--set hub.config.CryptKeeper.keys[0]=cccc3333
	# ingress.ingressClassName requires k8s 1.18 and above, don't
	# validate setting it against the k8s api-server on k8s 1.17.
	helm-template-validate-extra-args: >-
	--set ingress.ingressClassName=""
	create-k8s-test-resources: true

Several of these older versions have reached end-of-life according to https://endoflife.date/kubernetes
Can we drop some old versions? If we do we should ensure all the other test parameters are still tested

Alternative options

Do nothing

Who would use this feature?

Developers benefit from not needing to ensure compatibility with older K8s versions

(Optional): Suggest a solution

• Drop versions that have reached EOL?
• Drop versions that reached EOL more than X years ago?

[manics]

If we're going by public cloud support:

• 1.19 is unsupported
• Amazon: 1.20 support ends 01 Sep 2022 https://endoflife.date/amazon-eks
• Google: 1.20 support ends 01 Aug 2022 https://endoflife.date/google-kubernetes-engine
• Azure: 1.20 support ends Mar 2022 https://docs.microsoft.com/en-gb/azure/aks/supported-kubernetes-versions?tabs=azure-cli#aks-kubernetes-release-calendar

[consideRatio]

@manics ❤️ 🎉 this was a very relevant question for #2590! In there, it would help to drop support for 1.20, but I'm planning on maintaining functionality with 1.17 - 1.20 still because I presume it's considered a bit early to drop support for 1.20 and 1.17 keeps working if I get 1.20 working anyhow.

I'm inclined to say following the cloud providers is a reasonable practice. I like that a lot more than for example supporting everything until we observe things no longer work, and then drop support for old versions. If we want to be a helm chart that is "secure by default", it wouldn't hurt to require an overall still supported k8s version.

I'm +1 for dropping support for 1.17 to 1.19, and requiring 1.20+ as part of the next release.

[yuvipanda]

I'm inclined to say following the cloud providers is a reasonable practice.

+1, I love the info that @manics has put here. I'm +1 to requiring 1.20+ for 2.0

[consideRatio]

+1, I love the info that @manics has put here.

Me too! @manics thank you for being so generous with your time by providing so much relevant details - I think the total amount of time spent by us as a team reduced significantly by your time investment!

[damianavila]

I'm inclined to say following the cloud providers is a reasonable practice.

+1 as well!