https://rancher.com/ logo
Title
h

hundreds-evening-84071

02/22/2023, 1:44 PM
Have question about automated upgrades for k3s.... from this document https://docs.k3s.io/upgrades/automated I can specify channel and cluster is always automatically upgraded to the newest stable release of K3s. Is there a way to do n-2? Or perhaps only way to do that is to specify specific release like in example provided on same document above? Not sure if it matters, but I have HA cluster with etcd. running k3s version 1.22.9
c

creamy-pencil-82913

02/22/2023, 5:28 PM
I'm not sure what you mean by n-2. The channels are what's listed there - latest, stable, and one for each Kubernetes minor.
The upgrade controller will always put you in the latest version in a given channel
r

rich-cartoon-70161

02/22/2023, 6:28 PM
Ah. Cool I didn’t know about the channel feature yet. I can’t fully automate this because it rotates my rook-ceph nodes too quickly. Somehow it would be nice to have it wait until some command (eg ceph status) returns something (health-ok). Is that possible?
c

creamy-pencil-82913

02/22/2023, 6:42 PM
you can write a plan to do whatever you want
the page you linked to has links to both the release channels list, and to the system-upgrade-controller repo which has more documentation on SUC plans and some examples
r

rich-cartoon-70161

02/22/2023, 8:28 PM
ah jeah right, the “prepare” step could be used for that. but the “default” https://github.com/rancher/system-upgrade-controller/blob/master/examples/k3s-upgrade.yaml#L42-L45 which does https://github.com/k3s-io/k3s-upgrade/blob/master/scripts/upgrade.sh#L65-L89 is also useful… so I would have to bake some own k3s-upgrade image which additionally does some checks there. But well, maybe some time in the future 😄
c

creamy-pencil-82913

02/22/2023, 8:35 PM
I don’t think so, I bet you can get everything you need out of the existing image with some tweaks to the plan
r

rich-cartoon-70161

02/22/2023, 8:56 PM
hmmmm, I don’t really see how to easily add additional behaviour instead of replacing it. The
Prepare
(upgrade.cattle.io/v1/types.go#L44) is just one container which has to do all the logic. if it would be a list of contains like initContainers which all have to terminate before the upgrade starts… easy 😄 but adding “wait for ceph health to be OK” without replacing the whole logic about the “k3s-upgrade/prepare” with checking if the master plan exists and versions match… no idea yet.