breaking: start require k8s 1.20+ and test against k8s 1.20 and latest

[consideRatio]

Is the mybinder.org federation beyond k8s 1.19 at this point?

Z2JH requires k8s 1.20 currently, see jupyterhub/zero-to-jupyterhub-k8s#2635. @manics made a great job documenting the status of various cloud providers in jupyterhub/zero-to-jupyterhub-k8s#2591 (comment). In short, k8s 1.19 is not supported by Google, Amazon, or Azure.

While we could wait to bump this until we run into a need raise the lower level, I'd prefer to not wait. If we realize there is a need to raise the lower lever, then suddenly the person fixing something ends up needing to side-track and do this breaking change first before etc. In other words, by doing this now, we avoid slowing down and blocking something else when we really need to do it.

[sgibson91]

This looks ok to me, but I will leave a more "official" approval to someone with a little more context. I am unsure about the implications of this on the federation.

[manics]

Main determinant is whether all members are running at least K8s 1.20. If they are this should be fine to merge and deploy.

Might be nice to include the K8S version in

binderhub/binderhub/base.py

Lines 236 to 254 in 656204b

	class VersionHandler(BaseHandler):
	"""Serve information about versions running"""
	# demote logging of 200 responses to debug-level
	log_success_debug = True
	# allow version-check requests from banned hosts
	# (e.g. mybinder.org federation when blocking cloud datacenters)
	skip_check_request_ip = True
	async def get(self):
	self.set_header("Content-type", "application/json")
	self.write(
	json.dumps(
	{
	"builder": self.settings["build_image"],
	"binderhub": binder_version,
	}
	)
	)

? Though there's a security tradeoff.

[consideRatio]

I opened #1495 about the idea @manics, I see great value in it. Currently I'm positive to the idea.

[consideRatio]

All the members are good atm, I'm not sure about gesis though, but if gesis is at 1.19 or older it makes sense to error if time is used to update the binderhub helm chart rather than the k8s cluster's version.

Turing: v1.21
GKE Staging: v1.21
GKE Prod: v1.21
OVH: v1.20

With this, I'll move onwards.

[MridulS]

GESIS is still at v1.19 (I will update it ASAP) but interestingly the upgrade went through to the latest release (0.2.0-n960.h47d7917) without any error.

[consideRatio]

@MridulS oh, that is very weird. What version of the helm CLI are you using? Maybe it is because binderhub is a dependency chart for the chart you actually install, but that seems off anyhow.

@MridulS btw, also note that there is a lot of misc changes of relevance to make to unstuck from old k8s versions and old helm chart dependencies. These are mentioned in jupyterhub/mybinder.org-deploy#2182.

With regards to upgrading your k8s version, I think you should upgrade to k8s 1.21, but no further at this point, because of the migration steps needed to be done first in the issue linked above. I think we are stuck at k8s 1.21 now to support the mybinder helm chart. But, it would be good if you are at 1.21 like most others at that point in time.

[MridulS]

helm is at v3.6.3 (very well could be a bug somewhere in helm) and yes it's a dependency chart.

Thanks for the heads up!

I will update the cluster to v1.21 then :)