https://rancher.com/ logo
Join Slack
Powered by
This message was deleted.
# k3s
a
This message was deleted.
c
thats it
thats all that the automated upgrades do too. replace the binary and kill the process so that it gets restarted.
f
I've been draining & rebooting nodes during upgrades, but I just tried it with live workloads and it didn't seem to be disruptive
I'm playing cluster upgrade catchup the past few weeks.
c
its supposed to be nondisruptive, yes. Unless there’s something that requires the pod sandbox to be recreated, in which case the pods will get restarted afterwards.
f
gotcha
c
thats pretty unusual though
f
I took an old dev cluster from 1.23 to 1.30 (through every major release) and I think I ran into that along the way. I also had to switch the flannel backend from wireguard to wireguard-native, which was disruptive (and I expected)
c
thats a lot of upgrading!
f
yeah lol
For whatever reason I (and others) had a notion that k8s upgrades were harrowing tasks and hearing some shops suggest that it was easier to create a new cluster and migrate workloads to the new cluster
We just assumed that's what we'd have to do
maybe it is with vanilla kubernetes
c
There are occasionally things that require getting hands on… like the change from beta to v1 for CRDs… or the switch from PSP to PSA. Generally upgrades are a non-event though.
f
But with k3s, I've basically been doing a basic log scrub for "deprecated" messages, skimming reading the K8S deprecations, and then reading the urgent upgrade notes. Occasionally I've had to make some changes, but it's not too bad.
Most of the v1beta -> v1 changes have been "old resources are available at the new API version"
c
I’ve been upgrading my homelab by just replacing binaries for over 4 years.
Copy code
pi02.lan.khaus    Ready    <none>                 2y10d   v1.30.4+k3s1   10.0.1.24     <none>        Ubuntu 24.04 LTS   6.8.0-1010-raspi   <containerd://1.7.20-k3s1>
seago.lan.khaus   Ready    control-plane,master   4y99d   v1.30.4+k3s1   10.0.1.20     <none>        Ubuntu 24.04 LTS   6.8.0-41-generic   <containerd://1.7.20-k3s1>
f
Most of the time it's been making sure the operators are supported on a specific release
but even that's been pretty flexible
I did foot-gun our install a couple weeks ago where I tried to use the Rancher dashboard to upgrade Longhorn. Ultimately, that mistake wasn't even that bad, I had everything all the stateful services back up and running after 3hr.
Hot tip -- don't do that. The Rancher dashbaord uses the rancher-charts repo, which packages Longhorn differently
On the topic of k3s vs rke2 -- I think you might have mentioned this a while ago (month), but do the two distributions more or deploy and operate the same way? Just that rke2 just comes with more of the k8s fat (kinds & controllers)?
c
Rke2 is downstream of k3s. Most of the code is in k3s. Rke2 just runs all the Kubernetes components as static pods instead of in a single process, and has different bundled add-ons.
f
gotcha, for whatever reason I actually didn't expect rke2 to be downstream of k3s
The extra bit I'm looking for is honestly the volume snapshot stuff - I'm wanting to use Velero to do backups, and I suspect it needs that
c
those are super easy to install, the value of packaging them is pretty low. I wouldn’t switch distros just for that.
you could just HelmChart them super easy
you can find an example at https://github.com/k3s-io/k3s/pull/6459
we thought about it but decided not to
f
Thanks for the pointer, we'll probably just wind up adding it to our clusters
4 Views
Open in Slack
PreviousNext
Powered by