Upgrade hub and k8s to latest versions

I have a jupterhub (zero to jupyterhub) installation on k8s.
Currently, I am running 0.10.6 version of hub on k8s 1.16.15.

I am planning to upgrade both hub and k8s and I am interested in knowing the compatibilities between the two.

My plan is to upgrade hub to 1.1.5 and k8s to 1.19.13.

As per the release notes: zero-to-jupyterhub-k8s/CHANGELOG.md at 6dd8c79eefdef0b8271d0459f102abb63b916c74 · jupyterhub/zero-to-jupyterhub-k8s · GitHub
it seems that version 1.0.0 is not compatible with 1.16.15. My plan is to do the following

  • Upgrade helm chart + hub container image to 0.11.1 while keeping the k8s version to 1.16.15
  • Upgrade k8s to 1.19.x
  • Upgrade helm + hub to 1.1.5

Is 0.11.1 compatible with both 0.16.15 and 0.19.x?
Are all apis used in 1.1.5 compatible with 0.19.x?
Any other thing that I should keep in mind?
Thanks

I’m not sure about what 1.1.5 referred to (1.1.4 or 1.2.0 are helm chart versions, 1.1.5 isn’t a valid helm chart version). It’s fine to upgrade straight from 0.11.1 to 1.2.0 I think.

I suggest trying…

  1. Upgrade JH helm chart to 0.11.1
  2. Upgrade k8s to 1.19
  3. Upgrade JH Helm chart to 1.2.0

Related:

Is 0.11.1 compatible with both 0.16.15 and 0.19.x?

It is compatible with k8s 1.16.x for sure, but is it compatible with k8s 1.19.x? I think so yeah, but I’m not 100%, only like 90%. If you need to verify it, you can clone the jupyterhub/zero-to-jupyterhub-k8s repo and use the github workflow that validates rendered templates against various k8s versions and trial the 0.11.1 version against k8s 1.19.

Actually, it seems that during 0.11.1, it was tested against k8s 1.16 to 1.20: https://github.com/jupyterhub/zero-to-jupyterhub-k8s/blob/ca859aafb41d4081388ea5790c26e69b106e91e3/.github/workflows/test-chart.yaml#L76-L86 - I’m feeling 99.9% confident it is fine to use 0.11.1 against k8s 1.19 now.

Sorry for the confusion.
In the release notes of 1.2.0, it was written that you can upgrade to the hub image 1.1.5 to get the security patch even though there is no helm 1.1.5.

Thank you for the info.
It seems that both paths would work

  • direct upgrade to 1.2.0 on 1.16.x k8s
  • multi step upgrade like you mentioned.

Thanks

One more thing, the images that we launch through hub e.g jupyter/scipy-notebook (GitHub - jupyter/docker-stacks: Ready-to-run Docker images containing Jupyter applications), can be upgraded regardless of the hub or k8s version?

I am using an old version of pyspark-notebook and want to upgrade to the latest one but was confused what is the right time to upgrade. It seems that they should be independent and should work regardless of which hub and k8s version is used.

Further, the tags are very confusing. On the page → Docker Hub
I see tags representing git commits like 6e246ea4bbff, 2021-11-20, ubuntu-20.04, notebook-6.4.5 etc. Is there any documentation what these tags mean and which one to use?

Ah, this referred to jupyterhub version 1.5.0 I think.

One more thing, the images that we launch through hub e.g jupyter/scipy-notebook (GitHub - jupyter/docker-stacks: Ready-to-run Docker images containing Jupyter applications), can be upgraded regardless of the hub or k8s version?

Yepp, but they have a JupyterHub version, and sometimes you need to have a JupyterHub version centrally that matches the jupyterhub version in the user image.

This is related to the jupyter/docker-stacks project, and in short my summary is that there is a Dockerfile that is built regularly for multiple platforms. The most common one, amd64 aka x86_64 is inspected for what version of various packages it contains, then the same built image is tagged multiple times with various tags to reflect various versions that perhaps the end user wants to ensure they work against - if jupyterlab, notebook, or other packages are important to pin for the end user.

Documentation about this, hmmm, look at Jupyter Docker Stacks — Docker Stacks documentation for something about that I guess.

Yepp, but they have a JupyterHub version, and sometimes you need to have a JupyterHub version centrally that matches the jupyterhub version in the user image.

Thank you for the tip, will try to keep the version same during upgrade.

Thank you for the summary about the image tags, I understand the reason now.

1 Like