Rancher Server ↔ Cluster Agent: Should stale agent pods be auto‑removed on version skew?

Goal: Determine whether Rancher should automatically remove stale cluster‑agent pods when a version mismatch is detected between the Rancher server and a downstream Kubernetes cluster, given that the memory‑leak fix in v2.5.13/v2.6.0 resolved goroutine growth but no automated cleanup exists for version‑skew scenarios.

Constraints: The current behavior leaves old agent pods running until manual deletion or cluster eviction, which can accumulate resources during upgrade windows; it is unclear what triggers or thresholds would be safe for automatic removal without disrupting workloads or violating pod disruption budgets.

Should Rancher introduce an automated eviction policy for cluster‑agent pods that report a version mismatch?

What version‑delta or time‑based criteria should trigger such cleanup to balance safety and resource reclamation?

How would this automated cleanup coexist with existing pod disruption budgets and cluster autoscaler policies to avoid unintended downtime?