Closed brandond closed 1 month ago
Some other testing considerations additional to what has already been listed
--server
arg in the command as the other node. For example, using the examples above, from node-2, run: k3s etcd-snapshot save --server https://172.17.0.8:6443
I am fixing this by changing the flags for server/token to etcd-server/etcd-token. The use case for this was primarily for folks that for some reason changed the bind address or supervisor port and needed to override the server address to match. We weren't REALLY expecting folks to run the command against other nodes.
-$ k3s version v1.30.2+k3s-37830fe1 (37830fe1)
Infrastructure Cloud EC2 instance
Node(s) CPU architecture, OS, and Version: ubuntu AMD
Cluster Configuration: -3 node server -1 node agents
Environmental Info: K3s Version: v1.30.2+k3s2
Node(s) CPU architecture, OS, and Version: n/a
Cluster Configuration: Any cluster using embedded etcd with more than one server
Describe the bug: This is a regression introduced by
9816
When running
k3s etcd-snapshot
commands, theserver
flag defaults to the local server address, so etcd snaphots are created/listed/deleted on the local node. However, if the local server was joined to a cluster by specifying aserver
in the config file, theetcd-snapshot
commands are executed against THAT server, instead of the local server.This was reported in https://github.com/rancher/rke2/discussions/6284 but it took me a moment to realize what the user meant - I thought they were expecting the snapshot commands to be able to delete snapshots taken by other nodes (which is kind of what this is actually doing)
This is also likely the root cause of the multiple concurrent snapshot requests from https://github.com/k3s-io/k3s/issues/10371 - rancher's snapshot save commands were all being sent to the init node, instead of running locally on the individual servers.
Steps To Reproduce:
server:
address of the first node specified in the config file.Expected behavior:
etcd-snapshot
commands work against the local server by default, even when a server address is present in the config fileActual behavior: As described above
Additional context / logs: