Closed optix2000 closed 3 years ago
That is correct. At the moment, all etcd nodes must be able to reach each other via their internal IPs. Due etcd's requirement for low latency between nodes, we don't generally expect to see it deployed in a distributed configuration.
I'm a bit curious about this. Since this prevents using the embedded etcd for regional HA. This also prevents odd network configurations from working, even if they are low latency <5ms.
Due etcd's requirement for low latency between nodes, we don't generally expect to see it deployed in a distributed configuration.
Where does etcd require this? From their docs their default heartbeat interval is 100ms, which in turn allows for 50-150ms of latency between etcd nodes.
At some point we might extend it so that the server can also advertise the external IPs in the client and peer endpoint lists, but for the initial implementation we wanted to keep things pretty basic and easy to support. This means traditional lan deployments only.
Hello @brandond,
This means k3s will never support multi-region cluster either external DB ? (because of the latency)
This is just for embedded etcd not external databases. You're welcome to try whatever you like, but if the latency is high, performance will probably suffer.
This repository uses a bot to automatically label issues which have not had any activity (commit/comment/label) for 180 days. This helps us manage the community issues better. If the issue is still relevant, please add a comment to the issue so the bot can remove the label and we know it is still valid. If it is no longer relevant (or possibly fixed in the latest release), the bot will automatically close the issue in 14 days. Thank you for your contributions.
Environmental Info: K3s Version:
Node(s) CPU architecture, OS, and Version: Stock Debian 10
Linux k3s2 4.19.0-13-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28) x86_64 GNU/Linux
Cluster Configuration: 3 masters. 1 in a NAT with all traffic forwarded, the others have public IPs.
Host A:
Host B/C:
Describe the bug: Etcd fails to connect as it tries to use Host A's internal IP and softlocks k3s in an infinite loop.
As an aside, etcd never retries as the server shuts down, which could cause issues if there's a transient network issue.
Steps To Reproduce:
curl -sfL https://get.k3s.io | K3S_TOKEN=test sh -s - --cluster-init
curl -sfL https://get.k3s.io | K3S_TOKEN=test sh -s - --server https://<host-A-external-IP>:6443
Trying to pass
--node-external-ip <host-A-IP>
on Host A doesn't affect etcd.Reversing the roles (ie Host B cluster-init, Host A connect), doesn't work either, and results in a slightly different error
Expected behavior: etcd bootstraps uses external IP of Host A instead of internal IP.
Actual behavior: etcd tries to bootstrap using internal IP of Host A and fails to connect (as it's an internal IP).
Additional context / logs: Host B logs: