This message was deleted.
# rke2
a
This message was deleted.
s
Guessing there's some protection when editing a cluster (which is where that info is stored) that prevents the version being changed to something that's incompatible
e
I mean, im not mad. I'm learning, so I expected to break something. 🙂
I guess I didn't understand that RM isn't directly tired to the RKE2 version, when I upgrade that. Is that what people mean from above, when they are talking about "pre-release."
I guess maybe easier to ask, "In the Future, and in Production One Day, and I supposed to wait for RKE2 and RM to both match, before starting upgrades?"
c
You must always ensure that all clusters touched by Rancher - both the cluster Rancher runs on, and clusters managed by Rancher, are running versions of Kubernetes supported by your Rancher version.
If you don’t do that, the results are undefined.
e
Very Cool. Lesson better learned now, lol Is there a supportable way down, from 1.29? Can I just re-run the upgrade shell command like:
curl -sfL <https://get.rke2.io> | INSTALL_RKE2_VERSION=v1.27.12+rke2r1 sh -
And do what I did in reverse?
c
no, Kubernetes does not support downgrades from one minor to an older one. You should start over with a version supported by Rancher.
e
ooof. If I just operate as-is with unsupported versions, is there a pathway to when rancher does support it, it will align again?
c
maybe? certainly not something we test or support so idk
next patch release should support 1.28, 1.29 is a bit further out.
If you’re not in production yet, why not just start over with correct versions?
you did this all with IaC right?
e
nah just started this week, had to do it baremetal, and maybe just got too excited? lol
We're not on harvester yet, so baremetal * 5, but I could just probably uninstall and reinstall RKE Server.
I mostly just needed it up, so I could start validating and learning the F5-CIS portion, but failed miserably there.