Bundle kubectl image with system-upgrade-controller image in an image tarball

[manuelbuil]

Thanks for helping us to improve the system-upgrade-controller! We welcome all feature requests. Please fill out each area of the template so we can better understand the request. You can delete this message portion of the bug report.

Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] When deploying in Airgap environments (using tarball installation), there is a tarball for the system-upgrade-controller image. However, we also need to include the kubectl image but the required version is not that obvious. We need to inspect the yaml file that install system-upgrade-controller and check the kubectl image version.

If both images were part of the image tarball, the automatic upgrade in airgap scenarios would be easier to prepare.

Describe the solution you'd like A clear and concise description of what you want to happen.

Adding a tarball "bundle-kubectl-suc.tar.gz" in /var/lib/rancher/${distro}/agent/images/ will upload both images in the containerd image registry

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

1 - Look at the suc manifest and check what kubectl version is needed 2 - Docker save that kubectl image 3 - scp that image to the airgap node 4 - Place that image in /var/lib/rancher/${distro}/agent/images/

By doing this, we would save 3 steps

Additional context Add any other context or screenshots about the feature request here.

[brandond]

When deploying in Airgap environments (using tarball installation), there is a tarball for the system-upgrade-controller image. However, we also need to include the kubectl image but the required version is not that obvious.

Can you point at where specifically you're finding an airgap image tarball that includes the SUC image, but does not include docker.io/rancher/kubectl?

[manuelbuil]

In the release, right? https://github.com/rancher/system-upgrade-controller/releases/download/v0.16.2/system-upgrade-controller-amd64.tar

manuel@localhost:~> docker load -i /home/manuel/Downloads/system-upgrade-controller-amd64.tar
8b6272acc1bb: Loading layer [==================================================>]  50.65MB/50.65MB
a69fc3c61fd8: Loading layer [==================================================>]  864.8kB/864.8kB
Loaded image: rancher/system-upgrade-controller:v0.16.2
Loaded image: rancher/system-upgrade-controller:latest
manuel@localhost:~> docker image list
REPOSITORY                          TAG       IMAGE ID       CREATED      SIZE
rancher/system-upgrade-controller   latest    da141d00dc09   7 days ago   51.1MB
rancher/system-upgrade-controller   v0.16.2   da141d00dc09   7 days ago   51.1MB

[brandond]

Huh, I guess that was added back in:

• https://github.com/rancher/system-upgrade-controller/pull/26.

I wasn't paying attention when that went in - I believe it was mostly done to make it easier to break out the CI steps into discrete steps and just pass artifacts between them. I don't think we reference use of it anywhere so I'm not sure it was meant for end-users to consume. That said, I guess we could add the kubectl image to it...

[manuelbuil]

Yeah, we were wondering with Derek also why it was not as compressed as other image tarballs (e.g. rke2).

The whole story is that I was surprised to see that the upgrade section in the Airgap docs, only mention private registry: https://docs.k3s.io/installation/airgap?airgap-upgrade=Automated+Upgrade#3-upgrading. Then I tried upgrading using the tarball method to import images and noticed that the kubectl image was missing in the suc tarball (BTW rke2-upgrade/k3s-upgrade do not realease with any image tarball). As all those images were missing, I started wondering if perhaps it is not really recommended to do the upgrades importing images by tarballs, and that was the reason why it was not well documented.

[brandond]

Yeah I guess for airgap environments we just kinda expect users to have an internal registry and a workflow to pull/push images into it, rather than using airgap images for everything. Manually shuffling tarballs around to a bunch of nodes doesn't really scale very well.