Rancher

Rancher is SUSE's open source Kubernetes management platform for running many clusters across clouds, data centres and edge sites, with quoted paid editions.

Rancher gives platform teams one console for creating, importing and running Kubernetes clusters, whatever distribution or cloud each one sits on. It was started in 2014, when Docker had just arrived and teams were asking how to manage, secure and orchestrate containers. In 2020 Rancher became part of SUSE, the enterprise open source company, and it is still developed as open source software. SUSE builds its commercial editions, SUSE Rancher Prime and SUSE Rancher Suite, on the same platform. Teams provision new clusters with RKE2, K3s or the hosted services EKS, AKS and GKE, or import clusters built with any other distribution or installer. Inside each cluster, projects group namespaces under role-based access control, resource quotas and project network isolation. Workloads get services, ingresses with SSL termination, storage classes, config maps and secrets, the horizontal pod autoscaler and upgrades with rollback. Continuous Delivery with Fleet applies manifests from Git repositories, a Helm chart catalog installs packaged software, and Kubernetes version upgrades run from the cluster view. Prime adds the AI agent Crew with MCP, Virtual Cluster GPU multi-tenancy, AI observability and the Application Collection of hardened images. Rancher fits platform engineering and operations teams responsible for more than a handful of clusters, especially when those clusters span data centres, public clouds and edge sites. Organisations running EKS or AKS beside on-premises RKE2 or K3s use it to give every cluster one access model and one upgrade path. It also suits teams moving deployments to GitOps, because Fleet is part of the platform. Enterprises that want 24x7 support from SUSE, hardened application images or GPU sharing between tenants are the audience for SUSE Rancher Prime. Much of the routine work runs through Fleet: a change merged into a Git repository reaches every matching cluster without a manual step. Operators roll Kubernetes upgrades through control plane and worker nodes from the cluster view, with node draining set in the upgrade strategy. Application teams install software from Helm charts and roll a workload back to an earlier revision when a release misbehaves. On AWS, the cluster autoscaler grows custom clusters through EC2 Auto Scaling Groups when pods cannot run for lack of resources. That leaves one place where a platform team keeps every cluster on the same versions, policies and applications.