Retrieve URL for Kubernetes Multi-Version Upgrades in Airgap Environments

How do I?
1

Hey -

We have a customer who is an airgapped environment using the embedded installer that is currently on version 1.24 which was defined within the installer itself.

We bumped the version of k8s up to 1.28 in the next release in the channel, and we are looking to upgrade this customer to that version.

I know that when you run the install.sh | sudo bash -s airgap command and you’re jumping multiple versions the script will tell you the k8s package you need to download to do multiple version jumps:

You can download them with the following command:
    curl -LO https://kurl.sh/bundle/version/v2024.08.12-0/.../packages/kubernetes-1.25.14,kubernetes-1.26.15,kubernetes-1.27.16.tar.gz

We want to try to tell customers to download this package before we start the upgrade, rather than during, as typically AG installs require a lot of hoop jumping to get the files off of the public internet and onto their servers.

My question is: is there a way to reliably determine what the URL will be without needing to run the actual install.sh script? The scenario I am thinking is this:

  1. We run the installer ourselves in our own environment to generate the k8s kurl URL, and share this with the customer.
  2. The customer then waits a while, then proceeds to go download the installer tarball from their customer page. I believe at this point in time, the install.sh script is generated, which may mean a different version of kurl and k8s versions than what we had when we downloaded our installer.
  3. The customer downloads the k8s packages using the URL provided.
  4. During the upgrade, the version downloaded do not match the versions within the install.sh script they now have. Now we must re-download that file and transfer it.

Is my understanding correct in that the only way to guarantee the version in the script matches the downloaded k8s package is to make sure the customer downloads their installer at the same time we do OR to download the k8s package at the time of upgrade?

Thanks!

2

It’s possible to use static kurl versions (by downloading a bundle from https://k8s.kurl.sh/bundle/version/v2024.08.12-0/<installername>.tar.gz for instance), which may be what you’re looking for here - it would prevent the additional packages version from changing at the very least. Of course, if you changed your installer ot request k8s 1.29 instead of 1.28, you would of course have a new URL with an additional package in it.

3

Oh so if I understand it correctly, here’s the URL when you view it directly on the customer page:
https://kurl.sh/bundle/<installername>.tar.gz

Which is basically just:
https://kurl.sh/bundle/version/latest/<installername>.tar.gz

Which I’m guessing means you guys generate a new .tar.gz file every time a new version of kurl is released for all of the installers, which means potentially new patch versions of the k8s versions in the k8s steps, which would then lead you to:
https://kurl.sh/bundle/version/release_version_of_kurl/<installername>/packages/kubernetes-1.25.XX,kubernetes-1.26.XX,kubernetes-1.27.XX.tar.gz

But if we wanted to know it for sure, it would be (for the embedded installer):
https://kurl.sh/bundle/version/v2024.08.12-0/<installername>.tar.gz

Which then would mean we’d need to figure out the patch versions of k8s at the time for that version of kurl (or just check the install.sh script in the installer), and then the k8s package would be (change out the patch versions below to what’s in the install.sh script):
https://kurl.sh/bundle/version/v2024.08.12-0/<installername>/packages/kubernetes-1.25.XX,kubernetes-1.26.XX,kubernetes-1.27.XX.tar.gz

4

Yep, that’s the general answer! (We actually generate the bundles at download time and not at release time, though that doesn’t change anything for this)