Provisioned vs. Imported Clusters for Infrastructure Lifecycle Control

Infrastructure Management Trade-offs

When integrating Kubernetes clusters into Rancher, the choice between Provisioned and Imported clusters determines where the source of truth for infrastructure resides. Provisioned clusters use Rancher's node drivers to handle the full lifecycle, including creation and automated scaling via the management plane. Imported clusters rely on an agent deployment to bring existing clusters under management, decoupling the infrastructure layer from Rancher.

This creates a conflict for teams using external Infrastructure-as-Code (IaC) tools. Imported clusters avoid Rancher interfering with external provisioning workflows, but they lack integrated scaling and automated node replacement in the Rancher UI, and RBAC alignment may require manual effort.

• Provisioned: tight coupling with cloud credentials for full lifecycle automation.
• Imported: decoupled infrastructure management with manual scaling and RBAC requirements.

Which approach is more sustainable for environments requiring strict IaC-driven node lifecycles? Does the loss of Rancher-driven scaling in Imported clusters outweigh the credential coupling risk in Provisioned clusters? Should RBAC synchronization concerns affect this decision?