Rancher CAPI MachineDeployment node Ready status lag in UI

Question

Rancher uses Cluster API to abstract infrastructure providers and manages node lifecycle through MachineDeployment objects. The Rancher UI reflects downstream cluster state via the cluster-agent and Rancher's internal resource cache.

An unresolved behavior concerns the timing of node Ready status updates in the Rancher UI versus the actual Kubernetes API state during rapid scaling events. The same cache layer can introduce a latency gap between a resource deletion in the downstream cluster and its removal from the Rancher dashboard. Behavior is expected to vary between Rancher versions, for example 2.6 versus 2.7+, due to changes in the CAPI integration layer, and registration path characteristics can affect synchronization perception.

The goal is to clarify the documented synchronization semantics for node status and cache refresh during CAPI-driven scaling.

What is the documented update path and expected latency for node Ready status from downstream Kubernetes to the Rancher UI? Under which Rancher and CAPI versions does the UI surface MachineDeployment status versus Node status? Is the observed cache latency for deletions a configurable behavior or a known limitation?

Tasadduq Burney · Answer

Documented update path and expected latency
According to Rancher documentation, the cluster‑agent watches the downstream Kubernetes API for Node and Machine objects. When a Node’s Ready condition changes, the agent updates its internal cache and pushes the change to the Rancher UI via the server‑side proxy. The default sync (resync) interval is 30 seconds; with a lowered informer resync period the latency can be as low as 5 seconds.
Version‑specific UI behavior

Rancher 2.6.x: The UI shows only Node Ready status. MachineDeployment objects are not exposed; readiness is inferred from the underlying Node.
Rancher 2.7.0 and later: The cluster‑agent subscribes to Machine and MachineDeployment resources and maps their status to the UI, so both Node Ready and MachineDeployment readiness are displayed.

Deletion latency and configurability
When a Machine (and its Node) is deleted, the cluster‑agent processes the delete event and removes the entry from its cache. However, the cache may retain the stale Node for up to one additional sync cycle, producing a perceived lag of up to the sync interval. This interval is hard‑coded in the cluster‑agent source and is not exposed as a user‑configurable setting; changing it requires rebuilding the agent with a different resync period. Therefore the deletion lag is a known limitation, not a tunable parameter.
Steps to verify in your environment

Check the Rancher version (UI → About → Version) to determine which code path applies.
Enable debug logging for the cluster‑agent (set log level to debug) and watch for MachineDeployment add/update/delete events.
Run a scaling test: kubectl get machines -w in the downstream cluster and note the timestamp when a Machine disappears; simultaneously watch the Rancher UI or kubectl get nodes -w proxied through Rancher to see when the Node disappears.
Compare the two timestamps; the difference should align with the cluster‑agent sync interval (default ~30 s).

Missing diagnostic detail
Please confirm your Rancher version (e.g., 2.6.5, 2.7.2, 2.8.0) so I can tell you whether the UI should be showing MachineDeployment status versus only Node status.

Rancher CAPI MachineDeployment node Ready status lag in UI

1 answer

Documented update path and expected latency

Version‑specific UI behavior

Deletion latency and configurability

Steps to verify in your environment

Missing diagnostic detail

Your perspective belongs here.

0 question comments