Repository navigation
Replies: 2 comments
|
yes, your i'd check the file's modification time before changing anything: sudo stat /var/lib/rancher/k3s/server/cred/passwdthen line that timestamp up with deployment or restore history and clock corrections. a local rewrite of |
your etcd cluster lost quorum, or at least this node lost connection with its peers, and k3s exited as a result, as the local controllers could not renew their leases with the apiserver. I can't tell you what modified your passwd file, but K3s will only touch this on startup, when it verifies it against what's in the datastore. If the contents differ, but the one on disk is newer, then K3s refuses to start because it does not know why that might be. If you didn't modify that file on purpose, then the easiest fix is to just remove it and let k3s replace it with the content from the datastore. |
Uh oh!
There was an error while loading. Please reload this page.
Hello everyone,
I'm currently debugging a performance issue in my country-wide K3s cluster, and I'm encountering a seemingly unrelated issue with one of my node.
One of my K3s server spits this error at startup, after an unexpected (but seemingly clean) restart:
Here are the logs that precede:
My control-plane has three nodes,
greenbean,redbeanandwhitebean. At the time,greenbeanwas the leader, and was started with the following options:Can you think of anything that can lead to this situation? (the
passwdfile being newer than the etcd database (I assume that's what "datastore" means here))I'm not making this Q&A an issue, because I don't think there is anything wrong with K3s and strongly believe that there is something wrong with my deployment. Maybe this could lead to an improvement in the K3s documentation, but so far I'm too clueless to figure-out what' s going on here.
All reactions