Rancher Manager and Downstream Cluster Agent: Provisioning Timeout Logic

Cluster State Reconciliation

Rancher orchestrates downstream Kubernetes clusters by monitoring a bidirectional communication channel between the Rancher Manager and the cluster-agent. A cluster remains in the Provisioning state until the agent successfully completes a series of API handshakes and heartbeats with the management server.

Interoperability Constraints

The transition from Provisioning to Active is subject to timeout logic that must account for varying cloud provider node spin-up times and potential network latency. However, firewall restrictions or CA certificate mismatches can prevent the agent from reaching the Rancher API, leading to a state where the cluster hangs indefinitely or fails without a clear trigger.

Given the differences in bootstrapping between RKE and K3s workflows, the specific threshold for determining a failed provisioning attempt remains an area of configuration uncertainty.

• What is the default timeout duration before a cluster is marked as failed during the initial agent handshake?
• Can this timeout be adjusted globally or per-cluster to accommodate high-latency network environments?