Rancher fuer Multi-Cluster Kubernetes: Setup, Betrieb und Vergleich

TL;DR

• Rancher bietet eine zentrale UI und API zur Verwaltung beliebig vieler Kubernetes-Cluster -- On-Premise, Cloud und Edge
• Installation per Helm auf einem bestehenden Cluster in unter 10 Minuten
• RKE2 fuer produktionsreife On-Premise-Cluster, K3s fuer Edge und IoT mit minimalem Footprint
• Fleet (integriert in Rancher) ermoeglicht GitOps-basiertes Deployment ueber alle Cluster hinweg
• Rancher ergaenzt kubectl und native Cloud-Tools, ersetzt sie aber nicht

Warum Multi-Cluster Management?

Ab zwei oder drei Kubernetes-Clustern wird die Verwaltung manuell muehsam. Unterschiedliche kubeconfig-Dateien, divergierende Versionen, inkonsistente RBAC-Konfigurationen -- das alles summiert sich. Wer zusaetzlich Edge-Standorte, verschiedene Cloud-Provider oder On-Premise-Rechenzentren betreibt, steht vor einer echten operativen Herausforderung.

Rancher loest das, indem es eine einheitliche Steuerungsebene ueber alle Cluster legt. Man registriert bestehende Cluster oder provisioniert neue direkt aus Rancher heraus. Danach verwaltet man RBAC, Monitoring, Upgrades und App-Deployments zentral.

Das Ziel ist nicht, kubectl abzuloesen. Rancher ergaenzt es um eine visuelle Ebene und Automatisierung, die besonders in Teams mit unterschiedlichen Erfahrungsstufen wertvoll ist.

Rancher Architektur

Rancher besteht aus drei Hauptkomponenten:

Rancher Server: Laeuft als Deployment auf einem dedizierten Management-Cluster. Exponiert die Web-UI und die Rancher API. Speichert den Cluster-State in einer internen etcd- oder externen PostgreSQL/MySQL-Datenbank.

Cluster Agents: Auf jedem verwalteten Cluster laeuft ein Cluster Agent, der die Verbindung zum Rancher Server haelt. Der Agent oeffnet eine ausgehende WebSocket-Verbindung -- kein Inbound-Traffic noetig. Das vereinfacht Firewall-Regeln erheblich.

Fleet Controller: Ranchers integriertes GitOps-Tool. Fleet synchronisiert Helm Charts, Kustomize-Overlays oder Plain YAML aus Git-Repos in beliebig viele Cluster gleichzeitig.

Rancher Installation mit Helm

Voraussetzung ist ein bestehendes Kubernetes-Cluster (kann auch ein lokales K3s sein) mit mindestens 4 GB RAM und 2 CPUs fuer den Rancher Server.

# cert-manager installieren (Voraussetzung fuer Rancher TLS)
helm repo add jetstack https://charts.jetstack.io
helm repo update
helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --set crds.installCRDs=true

# Rancher Helm Repository hinzufuegen
helm repo add rancher-stable https://releases.rancher.com/server-charts/stable
helm repo update

# Rancher installieren
helm install rancher rancher-stable/rancher \
  --namespace cattle-system \
  --create-namespace \
  --set hostname=rancher.example.com \
  --set replicas=3 \
  --set ingress.tls.source=letsEncrypt \
  --set letsEncrypt.email=admin@example.com \
  --set letsEncrypt.ingress.class=nginx

# Status pruefen
kubectl -n cattle-system rollout status deploy/rancher
kubectl -n cattle-system get pods

Nach 2-3 Minuten ist die Rancher-UI unter rancher.example.com erreichbar. Beim ersten Login wird ein Admin-Passwort gesetzt.

Fuer Produktionsumgebungen empfehle ich:

• Mindestens 3 Replicas fuer den Rancher Server
• Einen dedizierten Management-Cluster (nicht auf einem Workload-Cluster)
• Externes TLS via cert-manager mit Let's Encrypt oder eigener CA
• Backup des Rancher-State via Velero oder etcd Snapshots

Cluster mit Rancher provisionieren

Rancher kann Cluster auf verschiedene Arten erstellen:

RKE2 (On-Premise): SUSE-Distribution, FIPS-140-2-konform, CIS-gehaertet out of the box. Ideal fuer regulierte Umgebungen und On-Premise-Rechenzentren.

K3s (Edge/IoT): Laeuft auf ARM und x86, benoetigt nur 512 MB RAM. Perfekt fuer Retail-Standorte, Produktionshallen oder Remote-Offices.

Hosted Provider: EKS, AKS und GKE lassen sich direkt aus Rancher heraus provisionieren oder als bestehende Cluster importieren.

Custom Cluster: Auf beliebigen Linux-Nodes per Registration-Command. Rancher generiert einen curl-Befehl, den man auf den Zielmaschinen ausfuehrt.

Hier ein Terraform-Beispiel fuer ein RKE2-Cluster via Rancher:

resource "rancher2_cluster_v2" "production" {
  name               = "prod-cluster"
  kubernetes_version = "v1.28.9+rke2r1"

  rke_config {
    machine_pools {
      name                         = "control-plane"
      cloud_credential_secret_name = rancher2_cloud_credential.vsphere.id
      control_plane_role           = true
      etcd_role                    = true
      quantity                     = 3

      machine_config {
        kind = rancher2_machine_config_v2.vsphere_cp.kind
        name = rancher2_machine_config_v2.vsphere_cp.name
      }
    }

    machine_pools {
      name                         = "worker"
      cloud_credential_secret_name = rancher2_cloud_credential.vsphere.id
      worker_role                  = true
      quantity                     = 5

      machine_config {
        kind = rancher2_machine_config_v2.vsphere_worker.kind
        name = rancher2_machine_config_v2.vsphere_worker.name
      }
    }

    machine_global_config = <<EOF
cni: calico
disable:
  - rke2-ingress-nginx
EOF
  }
}

Dieses Terraform-Modul erstellt ein RKE2-Cluster mit 3 Control-Plane-Nodes und 5 Workern auf vSphere. Die Konfiguration laesst sich versionieren und in CI/CD-Pipelines einbinden.

Rancher vs. native Tools: Vergleich

Die ehrliche Einschaetzung: Fuer ein einzelnes Cluster, das ein erfahrenes Team betreibt, bringt Rancher wenig Mehrwert. Der Nutzen steigt exponentiell ab 3+ Clustern, bei Mixed Environments (Cloud + On-Prem + Edge) oder wenn Teams mit unterschiedlichem Kubernetes-Know-how zusammenarbeiten.

Fleet: GitOps ueber alle Cluster

Fleet ist Ranchers integriertes GitOps-Tool und einer der staerksten Features der Plattform. Es synchronisiert Kubernetes-Ressourcen aus Git-Repositories in beliebig viele Cluster.

Das Konzept:

• GitRepo: Definiert ein Git-Repository und den Branch/Path
• BundleDeployment: Fleet erstellt automatisch Bundles aus dem Repo-Inhalt
• Cluster Groups: Cluster werden in Gruppen zusammengefasst, die dieselben Bundles erhalten

Fleet unterstuetzt Helm Charts, Kustomize und Plain YAML. Wer bereits ArgoCD oder Flux im Einsatz hat, kann diese auch parallel zu Fleet betreiben. Fleet fokussiert sich auf das Multi-Cluster-Deployment, waehrend ArgoCD pro Cluster arbeitet. Mehr zu GitOps-Strategien gibt es im Beitrag zu ArgoCD und GitOps.

RBAC und Projekt-Management

Rancher fuehrt eine zusaetzliche Abstraktionsebene ueber Kubernetes-Namespaces ein: Projekte. Ein Projekt gruppiert mehrere Namespaces und weist ihnen gemeinsame RBAC-Regeln zu.

Das ist nuetzlich in Organisationen, wo ein Team mehrere Namespaces nutzt (z.B. app-staging, app-production, app-monitoring). Statt RBAC dreifach zu konfigurieren, definiert man es einmal auf Projekt-Ebene.

Rancher integriert sich mit externen Identity Providern via SAML, LDAP oder OIDC. Benutzer authentifizieren sich gegen das bestehende Active Directory oder Keycloak und erhalten automatisch die richtigen Cluster-Berechtigungen.

Backup und Disaster Recovery

Der Rancher Server speichert seinen State entweder in der etcd des Management-Clusters oder in einer externen Datenbank. Beides muss regelmaessig gesichert werden.

Fuer den Management-Cluster empfiehlt sich Velero mit einem S3-kompatiblen Backend. Rancher bietet zusaetzlich den rancher-backup Operator, der Rancher-spezifische Ressourcen (Cluster-Definitionen, RBAC, Catalogs) separat sichert.

Wichtig: Die verwalteten Downstream-Cluster sind unabhaengig vom Rancher Server. Wenn Rancher ausfaellt, laufen die Workload-Cluster weiter. Man verliert nur die zentrale Verwaltung, nicht die Workloads.

Performance-Ueberlegungen

Der Rancher Server benoetigt bei 10-15 verwalteten Clustern circa 4 GB RAM und 2 CPUs. Bei 50+ Clustern sollte man mit 8-16 GB RAM und 4 CPUs planen. Der Cluster Agent auf den Downstream-Clustern ist mit unter 200 MB RAM und 0.5 CPUs sehr genuegsam.

Die WebSocket-Verbindung zwischen Agent und Server erzeugt minimalen Netzwerk-Traffic. Selbst ueber WAN-Verbindungen mit hoeherem Latenz funktioniert die Verwaltung zuverlaessig.

Wer den Monitoring-Stack fuer die verwalteten Cluster planen moechte, findet Hinweise im Beitrag zu Kubernetes Monitoring und Kostenoptimierung.

Security Hardening fuer Rancher

Rancher bringt einige Security-Features mit, die man aktiv einschalten und konfigurieren muss:

CIS Benchmark Scans: Rancher kann CIS Kubernetes Benchmark Scans direkt aus der UI starten. RKE2-Cluster bestehen den CIS-Benchmark weitgehend out of the box. Fuer importierte Cluster muss man die Ergebnisse manuell nacharbeiten.

Pod Security Standards: Seit Kubernetes 1.25 sind PodSecurityPolicies entfernt. Rancher unterstuetzt die neuen Pod Security Admission Controller. Man kann pro Namespace das Enforcement-Level setzen (privileged, baseline, restricted).

Network Policies: Rancher erstellt standardmaessig ein Project Network Isolation Feature. Wenn aktiviert, koennen Pods nur innerhalb ihres Rancher-Projekts kommunizieren. Fuer feinere Kontrolle setzt man zusaetzlich native Kubernetes NetworkPolicies oder Cilium-Policies ein.

Audit Logging: Der Rancher Server loggt alle API-Aufrufe. Diese Logs sollte man in ein zentrales Log-Management (Elasticsearch, Loki) exportieren. Fuer Compliance-Anforderungen nach ISO 27001 oder BSI-Grundschutz sind Audit Logs essenziell.

# Beispiel: Rancher Audit Log Konfiguration via Helm Values
# values.yaml fuer Rancher Helm Chart
auditLog:
  destination: file
  level: 2  # 0=off, 1=metadata, 2=request, 3=request+response
  maxAge: 30
  maxBackup: 10
  maxSize: 100

Fuer tiefergehende Kubernetes-Security-Themen empfehle ich den Beitrag zu Kubernetes Security Hardening.

Upgrade-Strategie

Rancher-Upgrades folgen einem klaren Pfad: Zuerst den Rancher Server aktualisieren, dann die Downstream-Cluster.

Rancher Server Upgrade:

# Aktuelle Version pruefen
helm list -n cattle-system

# Upgrade auf neue Version
helm repo update
helm upgrade rancher rancher-stable/rancher \
  --namespace cattle-system \
  --set hostname=rancher.example.com \
  --set replicas=3 \
  --version 2.9.2

# Rollout abwarten
kubectl -n cattle-system rollout status deploy/rancher

Downstream-Cluster Upgrade: In der Rancher UI unter Cluster Management den Ziel-Cluster auswaehlen und die Kubernetes-Version hochsetzen. Rancher fuehrt ein Rolling Upgrade durch -- zuerst Control Plane Nodes, dann Worker. Bei RKE2-Clustern kann man die Upgrade-Strategie konfigurieren (maxUnavailable, drain timeout).

Wichtig: Immer zuerst die Release Notes lesen. Rancher hat gelegentlich Breaking Changes zwischen Minor Versions. Ein Staging-Cluster zum Testen von Upgrades spart viel Aerger.

Typische Stolperfallen

Rancher auf einem Workload-Cluster installieren: Funktioniert technisch, ist aber riskant. Wenn der Cluster Probleme hat, verliert man gleichzeitig Workloads und Management. Immer einen dedizierten Management-Cluster verwenden.

Zu viele Cluster-Rollen: Rancher bietet granulares RBAC, was schnell zu einem Wildwuchs an Custom Roles fuehrt. Besser: Mit den eingebauten Rollen (Cluster Owner, Cluster Member, Project Owner, Project Member) starten und nur bei konkretem Bedarf anpassen.

Upgrades ueberspringen: Rancher und die verwalteten Kubernetes-Versionen sollten regelmaessig aktualisiert werden. Grosse Versionsspruenge sind problematischer als inkrementelle Updates.

Fleet ohne Staging: Fleet-Aenderungen immer zuerst in einem Dev/Staging-Cluster testen, bevor sie auf Produktion ausgerollt werden. Ein fehlerhaftes Bundle kann sonst alle Cluster gleichzeitig treffen.

Wann Rancher nicht die richtige Wahl ist

• Nur ein Cluster: Der Overhead lohnt sich nicht. kubectl und ein gutes Monitoring reichen.
• Reines Cloud-Setup bei einem Provider: Die nativen Tools (EKS Console, AKS Portal, GKE Console) sind fuer Single-Provider besser integriert.
• Maximale Kontrolle gewuenscht: Rancher abstrahiert Details weg. Wer jeden Parameter eines kubeadm-Clusters kontrollieren will, faehrt mit manuellem Setup besser.

Fuer die Grundlagen eines produktionsreifen Cluster-Setups lohnt sich auch ein Blick auf Kubernetes Production Cluster. Wer sich speziell fuer die Unterschiede zwischen Rancher und nativen Kubernetes-Distributionen interessiert, findet einen detaillierten Vergleich unter Rancher vs. Kubernetes.

Zusammenfassung

Rancher ist ein solides Multi-Cluster-Management-Tool, das seinen groessten Wert in heterogenen Umgebungen mit mehreren Clustern entfaltet. Die Kombination aus zentralem RBAC, Cluster Lifecycle Management, integriertem Monitoring und Fleet fuer GitOps macht es zu einer produktiven Plattform fuer Teams, die mehr als zwei Cluster betreiben.

Die Installation ist unkompliziert, die Lernkurve moderat. Der groesste Gewinn liegt in der Standardisierung: Alle Cluster werden gleich verwaltet, unabhaengig davon, ob sie On-Premise, in der Cloud oder am Edge laufen.

Wenn Sie Multi-Cluster Kubernetes evaluieren oder Ihre bestehende Rancher-Installation optimieren moechten, koennen wir helfen. Melden Sie sich unter /kontakt.