This message was deleted.
# general
a
This message was deleted.
c
did you look at the etcd docs? that seems like the more logical place to check. https://etcd.io/docs/v3.5/op-guide/maintenance/#defragmentation
Note that defragmentation to a live member blocks the system from reading and writing data while rebuilding its states.
p
I did see that but couldnt tell if that would have any impact on the running workloads or just folks using kubectl, the rancher docs on it just say ‘run this to fix etcd frag’ without any additional context
c
etcd blocks mean apiserver blocks. if the defrag takes more than about 10 seconds to complete you’ll probably see things start to freak out.
p
Ah so things like health checks etc?
c
I mean things like controllers not being able to renew their leases, and erroring out and crashing
p
😱
r
So defrag blocks access from all nodes and not just one at a time? I'd read the quote looking like with a three node cluster you'd have two functional etcd nodes while the other blocks a lot.
c
it blocks all access to that etcd server, and each apiserver generally only talks to a single etcd server
👍 1
I mean realistically you’ll probably be fine, but if you’re on slow disk or have an excessive amount of deleted data to defrag, you should consider doing it during a period of low utilization
p
Yea we will be trying to find a maintenance window as a lot of our workloads dont tolerate hiccups well, ty for the infos!
166 Views