Best way to upgrade Calico from 3.18 to 3.25

[joselitodasilva]

Hell all,
We have a self-managed on-premises Kubernetes (installed with kubeadm) created a few years ago, running with calico 3.17 installed using the manifests from the Calico install guide.

The cluster is currently on K8s 1.25 and we would like to upgrade Calico so we can continue to upgrade K8s with the right supported Calico versions.

What would be the best way to go about it? Remove the manifests and install the operator, helm, just change the image?
Appreciate any guidance
Regards,
Eduardo

[frozenprocess]

Pinging @lwr20

[lwr20]

Remove the manifests
just change the image

Please don't ever do either of those things, those are almost guaranteed to break your cluster.

What would be the best way to go about it?

You're a very very long way from supported versions. Kubernetes is currently on 1.32 and Calico is on v3.29.
Kubernetes only supports upgrade from minor version to minor version. i.e. you would have to do 7 kubernetes upgrades.
Calico allows skipping one minor version each time, so you would have to do 6 upgrades. (3.17-19, 3.19-21, 3.21-23, 3.23-25, 3.25-27, 3.27-29). You would need to ensure that at every point the Kubernetes/Calico pairing you're using is supported.

If, as I suspect, you're currently using a manifest Calico install, you should migrate to an Operator install as soon as possible (following the operator migration procedure for that version in the docs). If you do not do this, you will need to remember how you customised Calico for your environment, and re-apply those customisations at every version. Operator would take care of that for you. Follow the upgrade procedures in the Calico docs.

You get the idea - the above method is a lot of work and the chances of all that working without any problems at all is very small...

IMO the "best" way, would be to deploy a completely new cluster alongside the old with uplevel kubernetes, calico, etc with all your applications deployed in it, and switch over traffic from one cluster to the other using DNS records or loadbalancers. This method has the advantage of allowing you to run tests on the uplevel cluster before it goes live, check compatibility of all your applications with it and switch back to the downlevel cluster if despite all that testing it goes wrong anyway.

After the switchover, once you're certain everything is as it should be, you can delete the old cluster.