Hi Team, I've encountered an interesting behavior in my RKE2 cluster during updates to the FQDN configurations on my server nodes and would appreciate insights or explanations. Scenario: • My cluster consists of several server nodes, notably

server0

and

server1, server2

. • Recently, I updated the FQDN configuration for these servers.

server0

does not have a server entry in its RKE2 configuration, while

server1

does. • After applying the new FQDN config and restarting

server0

for the first time, I observed that other nodes in the cluster temporarily transitioned to a

NotReady

state before returning to

Ready

. • Interestingly, performing the same operation first on

server1

(which has a server entry in its config) does not cause the other nodes to enter a

NotReady

state. Questions: 1. Why does restarting

server0

(without a server entry) cause other nodes to temporarily become

NotReady

, whereas restarting

server1

(with a server entry) does not have the same effect? 2. Are there specific considerations or best practices when updating FQDN configurations in RKE2 clusters, especially concerning the server entries in the config files? 3. Could this behavior be related to how the RKE2 cluster manages internal DNS resolutions or certificate trust chains upon FQDN changes? Any guidance on understanding and ideally managing this behavior would be greatly appreciated. I'm aiming to ensure minimal impact on the cluster's availability and state consistency during configuration updates.