This page is intended to answer questions about what happens if you don’t want Rancher anymore, if you don’t want a cluster to be managed by Rancher anymore, or if the Rancher server is deleted.
- If the Rancher server is deleted, what happens to the workloads in my downstream clusters?
- If the Rancher server is deleted, how do I access my downstream clusters?
- What if I don’t want Rancher anymore?
- What if I don’t want my registered cluster managed by Rancher?
- What if I don’t want my RKE cluster or hosted Kubernetes cluster managed by Rancher?
If the Rancher server is deleted, what happens to the workloads in my downstream clusters?
If Rancher is ever deleted or unrecoverable, all workloads in the downstream Kubernetes clusters managed by Rancher will continue to function as normal.
If the Rancher server is deleted, how do I access my downstream clusters?
The capability to access a downstream cluster without Rancher depends on the type of cluster and the way that the cluster was created. To summarize:
- Registered clusters: The cluster will be unaffected and you can access the cluster using the same methods that you did before the cluster was registered into Rancher.
- Hosted Kubernetes clusters: If you created the cluster in a cloud-hosted Kubernetes provider such as EKS, GKE, or AKS, you can continue to manage the cluster using your provider’s cloud credentials.
- RKE clusters: Please note that you will no longer be able to manage the individual Kubernetes components or perform any upgrades on them after the deletion of the Rancher server. However, you can still access the cluster to manage your workloads. To access an RKE cluster, the cluster must have the authorized cluster endpoint enabled, and you must have already downloaded the cluster’s kubeconfig file from the Rancher UI. (The authorized cluster endpoint is enabled by default for RKE clusters.) With this endpoint, you can access your cluster with kubectl directly instead of communicating through the Rancher server’s authentication proxy. For instructions on how to configure kubectl to use the authorized cluster endpoint, refer to the section about directly accessing clusters with kubectl and the kubeconfig file. These clusters will use a snapshot of the authentication as it was configured when Rancher was removed.
What if I don’t want Rancher anymore?
As of Rancher v2.5.8, uninstalling Rancher in high-availability (HA) mode will also remove all
helm-operation-* pods and the following apps:
Custom resources (CRDs) and custom namespaces will still need to be manually removed.
If you installed Rancher with Docker, you can uninstall Rancher by removing the single Docker container that it runs in.
Imported clusters will not be affected by Rancher being removed. For other types of clusters, refer to the section on accessing downstream clusters when Rancher is removed.
What if I don’t want my registered cluster managed by Rancher?
If a registered cluster is deleted from the Rancher UI, the cluster is detached from Rancher, leaving it intact and accessible by the same methods that were used to access it before it was registered in Rancher.
To detach the cluster,
- From the Global view in Rancher, go to the Clusters tab.
- Go to the registered cluster that should be detached from Rancher and click ⋮ > Delete.
- Click Delete.
Result: The registered cluster is detached from Rancher and functions normally outside of Rancher.
What if I don’t want my RKE cluster or hosted Kubernetes cluster managed by Rancher?
At this time, there is no functionality to detach these clusters from Rancher. In this context, “detach” is defined as the ability to remove Rancher components from the cluster and manage access to the cluster independently of Rancher.
The capability to manage these clusters without Rancher is being tracked in this issue.
For information about how to access clusters if the Rancher server is deleted, refer to this section.