This message was deleted.
# k3sa
adamant-kite-43734
12/07/2022, 4:10 PMThis message was deleted.
c
creamy-pencil-82913
12/07/2022, 4:12 PMyou could do a rolling move, by deleting nodes from the cluster and then re-joining them with their new IP.
creamy-pencil-82913
12/07/2022, 4:13 PMas long as the two networks have connectivity with each other
w
wide-author-88664
12/07/2022, 4:15 PMThey kind of do… the new network is going to be behind a NAT gateway, so the old networks’ nodes won’t be able to communicate with new (moved) nodes… New nodes can easily talk to old nodes tho.
wide-author-88664
12/07/2022, 4:15 PMAnd, in this case, it’s only a two-node cluster…
Copy code
root@demo-nb-12110:~# kubectl get nodes
NAME STATUS ROLES AGE VERSION
demo-nb-12110 Ready control-plane,master 31h v1.25.4+k3s1
demo-nb-12111 Ready <none> 11s v1.25.4+k3s1c
creamy-pencil-82913
12/07/2022, 4:31 PMfor a single-server cluster you could probably get away with just stopping the server, running the killall script, and then bringing it back up with the new IP. Do the same with the agent, but change the server’s IP in the config before bringing it back up.
This is more complicated with embedded etcd, because you have to manage quorum while moving the nodes… but not a problem for you.
w
wide-author-88664
12/07/2022, 4:34 PMCool, thanks
3 Views