Replies: 2 comments 3 replies
-
Best practice is dont use DHCP, certainly for control plane nodes, as etcd communication will break. |
Beta Was this translation helpful? Give feedback.
2 replies
-
Alternatively, is there an efficient solution for fixing or updating static addresses in a three-master cluster created with Talos? |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Issue/Question
I'm running a 3-master Kubernetes cluster on Talos Linux where all node IP addresses are dynamically assigned via DHCP. I understand that Talos supports DHCP for IP allocation, but I'm concerned about what happens when the DHCP leases expire and the IP addresses change (e.g., due to lease timeout or DHCP server behavior).
Specifically:
What is the expected cluster state after IP addresses change? Will the cluster remain operational, or could it lead to issues like etcd peer disconnection, API server unavailability, or pod scheduling failures?
Is the cluster still stable in this scenario? For example, does Talos handle IP changes gracefully, or does it require manual intervention to recover?
If the IPs change, can I continue managing the cluster (e.g., via talosctl or kubectl) using the newly assigned IP addresses? Would I need to update any configurations, such as the kubeconfig or machine configs, to point to the new IPs?
From my understanding, Kubernetes components like etcd and the control plane rely on stable endpoints. If IPs change without static DHCP reservations, it might disrupt the cluster. I'd appreciate any insights, best practices, or documentation references on using DHCP in production Talos clusters.
Thanks for your help!
Beta Was this translation helpful? Give feedback.
All reactions