RKE2 Stable Channel Upgrade Information Request

[sarg3nt]

The docs are not clear on how the stable channel works.
I have the following questions:

1. Currently K8s v1.26, v1.27 and v1.28 are all considered stable as far as I can tell and I think I understand that the reason the stable channel is deploying v1.26 is because that is what Rancher supports (which is not in the docs BTW and should be) however what I can't find is how new version of k8s are chosen to be the next stable. I.E. it is best practice to upgrade sequentially, from 1.26 to 1.27 to 1.28 etc. Is there a "contract" in place that stable will always go to the next sequential release or do we need to manage that? i.e we would lock on v1.26 then choose when to go to 1.27, etc. It would be easiest for us to just lock on stable but we need to know if it sequentially upgrades or not. I get we'd need to keep up on changes to Kubernetes that could break our workloads but we have automation in place for that for our new install/upgrade mechanisms so I'm not worried that much about it.
2. I get that the first part of the version number is the version of k8s but what does the second part "+rke2r1" or "+rke2r2" mean? How do we know when changes are made to RKE2 specifically outside of the version of k8s?
3. If we decide to lock on a channel using the version tag, i.e. "v1.26" how can we tell when stable moves to 1.27 or 1.28? Is there an RSS feed, email or alerting mechanism or do we need to poll the release channels API?

[sarg3nt]

Oh, my bad, the stable / Rancher tie in is in the docs, sort of. It's not super clear that Stable is tied to Rancher just that it is compatible. i.e. the reason stable is on that version of k8s is because that's what Rancher supports is not super clear.

(Default) Stable is recommended for production environments. These releases have been through a period of community hardening, and are compatible with the most recent release of Rancher.

[brandond]

I think I understand that the reason the stable channel is deploying v1.26 is because that is what Rancher supports

That is correct.

What I can't find is how new version of k8s are chosen to be the next stable. I.E. it is best practice to upgrade sequentially, from 1.26 to 1.27 to 1.28 etc. Is there a "contract" in place that stable will always go to the next sequential release or do we need to manage that?

We move forward as Rancher moves forward. The Kubernetes version skew policy forbids skipping over minors, so we would never jump directly over a minor release as stable - although if you delay upgrading long enough, it is possible that you would miss the period where a specific minor was stable.

what does the second part "+rke2r1" or "+rke2r2" mean?

That's the release identifier; semver calls it "build metadata". If we ever have to do another release (for any possible reason) outside the normal Kubernetes patch cycle, we will bump the ordinal when releasing.

How do we know when changes are made to RKE2 specifically outside of the version of k8s?

You read the release note changelog?

If we decide to lock on a channel using the version tag, i.e. "v1.26" how can we tell when stable moves to 1.27 or 1.28?

If you're locked to a minor version channel, why does it matter to you what the stable channel points at?

[sarg3nt]

@brandond
Wow, thanks for the quick reply, much appreciated!

If you're locked to a minor version channel, why does it matter to you what the stable channel points at?

I'm in the midst of building our next gen k8s deployment system. We are using Kairos+Rocky Linux as an immutable base OS and going with the strategy of replacing nodes for upgrades. We want to automate this on a weekly basis to facilitate OS patching. I'm trying to work through our k8s upgrade strategy at the moment and think I'll probably just float on stable and rely on our test suite to ensure the test cluster is stable before upgrading any prod clusters. However, if the team decides we want to lock on a version of k8s and manually control when we upgrade to the next version I'd want a way to know and alert us when rke2 upgrades stable to the next version of k8s so we can take action. I'd prefer not to the do this but need to bring it as an option to the team.

[brandond]

I would probably target a specific minor, and be intentional about upgrades to new minors. There are always MUST READ callouts in the upstream release notes for new minors that I wouldn't want to miss prior to upgrading.

[sarg3nt]

Thank you, that makes a lot of sense.
Closing.