https://rancher.com/ logo
Join SlackCommunities
Powered by
This message was deleted.
# k3s
a
This message was deleted.
c
yes it is supported. it’s not the default for standalone clusters because it is much more disk IO intensive than sqlite. Rancher does provision all clusters with etcd, regardless of how many nodes.
s
I've started k3s with 
--cluster-init
but when I restart it with that option it says 
this server is a not a member of the etcd cluster.
This is running within another GKE cluster so I'd like to use the same arguments.
I read that but in my testing SQLite saturated the IOPS much sooner.
I'm using k3s in vCluster, not Rancher.
c
Are you forgetting to put the database files on a PV or something? That is not an error that you should see unless you’ve mucked about with things.
s
naw the vCluster helm chart puts both SQLite and etcd on the PV.
c
etcd requires static names and IPs, if you change that you’ll need to do a cluster-reset before starting, to update etcd cluster membership to the pod’s new name and ip.
s
ok that makes it sound like using k3s with embedded etcd is not supported if the IP addresses are not static, as when I'm running it within Kubernetes.
Thank you for the insight @creamy-pencil-82913 ! I got great performance by installing the bitnami etcd helm chart alongside k3s and connecting it, even with a single etcd node, so I'll probably continue doing that.
doing some more research, it looks like etcd cannot guarantee durability with only one node. that would explain why it's so much lighter on the disk.
or at least it's not recommended for production
c
well, nothing guarantees durability on a single node lol
I’m curious how you’re deploying etcd that it ends up being more lightweight than sqlite. I’ve always found the opposite.
s
deploying k3s as part of vCluster. might ask the Loft team if they've seen the same.
deploying etcd with the bitnami helm chart
4 Views
Open in Slack
PreviousNext
Powered by