Rancher war das perfekte Kubernetes-Dashboard — bis sich der Preis änderte
Lange Zeit fühlte sich Rancher wie das seltene Enterprise-Tool an, das es wirklich verstand. Nicht nur technisch, sondern auch emotional. Es gab Plattformteams etwas, das sie fast nie bekommen: Ruhe.
Ein Login. Ein Bildschirm. Zwanzig Cluster, verteilt über Accounts, Regionen und Teams, wirkten plötzlich verständlich. Man konnte einen Bereitschaftsingenieur, eine Support-Leitung oder eine Entwicklerin in dieselbe Oberfläche setzen und darauf vertrauen, dass sie sich zurechtfinden würde, ohne etwas kaputt zu machen. Für viele Teams wurde Rancher zur Steuerungsebene für Kubernetes selbst — die „Pane of Glass“, über die alle Witze machen, die sich aber insgeheim jeder wünscht.
Und dann änderte sich der Rancher-Preis.
Nicht nur ein bisschen. So sehr, dass die Leute aufhörten, über einzelne Posten zu diskutieren, und anfingen, existenzielle Fragen zu stellen. Fragen wie: Brauchen wir das wirklich? Und vielleicht noch schmerzhafter: Warum fühlt sich etwas, das sich früher wie eine Partnerschaft anfühlte, jetzt wie ein Verkaufsdruck-Test an?
Das ist die Geschichte, wie Rancher vom geliebten Dashboard zum Budgetproblem wurde — und warum es immer noch keinen naheliegenden Ersatz gibt.
Als Kubernetes zu groß wurde, um es im Kopf zu behalten
Einen Kubernetes-Cluster zu betreiben ist schwer. Zwanzig zu betreiben ist etwas völlig anderes.
In diesen Kontext ist Rancher vor Jahren eingestiegen. Teams waren bereits auf verwalteten Plattformen wie Amazon EKS unterwegs, aber EKS versuchte nicht, alles zu lösen. Es lieferte Cluster. Der Rest war Sache der Teams.
Rancher füllte genau diese Lücke. Es ersetzte Kubernetes nicht, es umhüllte es. Plötzlich fühlten sich Cluster nicht mehr wie Einzelfälle an. Die Authentifizierung war sauber an GitHub-Organisationen und Teams angebunden. RBAC hörte auf, eine YAML-Ausgrabung zu sein. Entwickler konnten Workloads skalieren, Pods neu starten oder Logs abrufen, ohne Cluster-Admin-Schlüssel und ein Stoßgebet zu bekommen.
Es war nicht spektakulär. Es war stimmig.
Diese Stimmigkeit wurde noch wichtiger, als das Monitoring ins Spiel kam. Rancher's eingebaute Prometheus-Ansichten versuchten nicht, den gesamten Observability-Stack zu ersetzen. Sie beantworteten nur die erste Frage, die sich alle stellen: Ist das Ding gerade kaputt? Für tiefere Analysen waren Tools wie Datadog oder Splunk weiterhin da und taten das, was sie am besten können.
Rancher verlangte keine Exklusivität. Es ergänzte. Deshalb vertrauten die Leute darauf.
Die Übernahme, vor der zunächst niemand Angst hatte
Als SUSE Rancher übernahm, fiel die Reaktion überwiegend vorsichtig optimistisch aus. SUSE war keine Private-Equity-Firma mit einer Geschichte des Ausschlachtens von Produkten. Es war ein langjähriges Open-Source-Unternehmen, das Enterprise-Kunden verstand.
Und um fair zu sein: Rancher wurde nicht plötzlich schlechter. Die Oberfläche brach nicht zusammen. Funktionen verschwanden nicht. Der Open-Source-Kern blieb offen.
Aber die Preisgestaltung? Die verschob sich. Zunächst leise, dann unübersehbar.
Was früher ein Support-Vertrag mit einem ungefähr sechsstelligen Jahresbetrag war, blähte sich zu etwas mehrfach Größerem auf. Nicht weil Teams ihre Cluster-Anzahl verdoppelt hatten. Nicht weil die Nutzung explodierte. Einfach weil sich das Rancher-Preis-Modell änderte.
Das war der Moment, in dem „Rancher-Preis“ aufhörte, ein Beschaffungsdetail zu sein, und anfing, ein Slack-Thema zu werden.
Die unbequeme Rechnung von Enterprise-Open-Source
Hier ist die unbequeme Wahrheit: Rancher ist immer noch kostenlos.
Man kann es betreiben, ohne SUSE einen Cent zu zahlen. Viele Teams tun genau das. Manche bauen sich sogar ihre eigenen Long-Term-Support-Images aus dem Upstream-Quellcode und lassen es dabei bewenden.
Aber Unternehmen kaufen nicht nur Software. Sie kaufen Ruhe.
Support-SLAs existieren für die Momente, in denen um 2 Uhr nachts etwas Subtiles kaputtgeht und der Schadensradius unbekannt ist. Sie existieren für Auditoren, Führungskräfte und das stille Versprechen, dass jemand anderes das Risiko mitträgt.
Wenn dieses Versprechen von „teuer, aber vertretbar“ zu „fünfmal so viel wie letztes Jahr“ springt, geht die Rechnung nicht mehr auf. Nicht weil das Tool an Wert verloren hätte, sondern weil der Wert nicht mehr mit den Kosten mitwuchs.
Es ist schwer zu rechtfertigen, Luxuswagen-Geld für ein Dashboard auszugeben, selbst wenn es das beste Dashboard ist, das man je genutzt hat.
„Nutzen Sie einfach natives Kubernetes“ ist technisch richtig und praktisch nutzlos
Wann immer Preisgespräche aufkommen, sagt zwangsläufig jemand den einen Satz: Sie brauchen Rancher nicht. Kubernetes kann das alles schon.
Sie haben nicht unrecht. Sie verfehlen aber auch den Punkt.
Ja, Kubernetes-RBAC kann Zugriffskontrolle übernehmen. Ja, Cloud-IAM-Integrationen sind solide. Ja, kubectl funktioniert einwandfrei, wenn man weiß, was man tut.
Aber bei Rancher ging es nie um rohe Fähigkeiten. Es ging um Ergonomie. Darum, Plattformteams zu erlauben, Cluster zu schützen, ohne zu Torwächtern zu werden. Darum, Entwicklern ein Gefühl von Handlungsfähigkeit zu geben, ohne ihnen die Schlüssel zum Königreich zu übergeben.
Deshalb sind Alternativen so schwer zu fassen.
Tools wie Headlamp bieten saubere, moderne Oberflächen, sind aber bewusst „nur eine Oberfläche“. Sie versuchen nicht, eine Plattform zu sein. Andere setzen auf GitOps, wo Argo CD glänzt — besonders in Kombination mit Dashboards von Grafana.
Das Problem ist, dass keines dieser Tools Rancher sein will. Und vielleicht ist genau das der Punkt.
Der Mythos des einen wahren Dashboards
Was Rancher unbeabsichtigt bewiesen hat, ist, dass Menschen nicht wirklich Dutzende erstklassiger Tools wollen. Sie wollen weniger Entscheidungen.
Sie wollen einen Ort, an dem Ops, Support und Entwicklung stehen können, ohne sich gegenseitig auf die Füße zu treten. Sie wollen sichere Buttons. Sie wollen Kontext.
Diese Erfahrung ohne Rancher nachzubauen bedeutet, einen Stack zusammenzusetzen, statt ein Produkt zu kaufen. Es bedeutet IAM hier, GitOps dort, Monitoring irgendwo anders — und zu hoffen, dass die Dokumentation gut genug ist, um alles zusammenzukleben.
Manche Teams sind mit diesem Kompromiss zufrieden. Andere geben leise zu, dass sie die alten Zeiten vermissen.
Rancher ist nicht gescheitert — es ist einfach aus seiner Rolle herausgewachsen
Das ist keine Geschichte über Verrat. SUSE liegt nicht falsch damit, Geld zu verlangen. Open Source erhält sich nicht von selbst. Ingenieure arbeiten nicht für Sichtbarkeit.
Aber Rancher besetzte eine merkwürdige Zwischenposition: zu kritisch, um optional zu sein, zu abstrakt, um Kerninfrastruktur zu sein, und jetzt zu teuer, um ein einfaches Ja zu sein.
Die Ironie ist, dass Rancher immer noch sehr gut in dem ist, was es tut. Es wird nur nicht mehr wie ein Tool bepreist, das man still verlängert. Es wird bepreist wie etwas, das man verteidigen muss.
Und sobald man ein Dashboard in einem Budgetmeeting verteidigt, hat sich bereits etwas verändert.
Der stille Ausgang, über den niemand spricht
Die meisten Teams werden Rancher nicht dramatisch herausreißen. Sie werden den Support herunterstufen. Versionen einfrieren. Nebenbei mit Alternativen experimentieren.
Sie werden es weiter nutzen — aber anders. Vorsichtiger. Weniger liebevoll.
Das könnte die aufschlussreichste Verschiebung von allen sein.
Denn Rancher war nicht nur Software. Es war Vertrauen, dargestellt als Oberfläche. Und Vertrauen, das zur Verhandlungssache wird, ist schwer zurückzugewinnen.