© Mark Bowden / 123RF.com

Rancher positioniert sich als eher leichtfüßige Alternative zu Red Hats OpenShift und ermöglicht den schnellen Einstieg in Kubernetes. Architektonisch unterscheidet sich ein Rancher-Setup von klassischem Kubernetes allerdings deutlich.

Viele Admins denken beim Schlagwort Kubernetes augenblicklich an die großen Produkte von Red Hat und Ubuntu. OpenShift von den roten Hüten beispielsweise ist eine riesige Kubernetes-Distribution mit etlichen Komponenten, die einen angeschlossenen App-Store für Container-Anwendungen bietet und unter der Haube mit viel Komplexität daher kommt. Etwas weniger hochtrabend hält es Rancher: Zwar gehört das Produkt mittlerweile auch zu einem großen Linux-Distributor, nämlich Suse, doch hält Suse sich bisher aus dem Werk der Rancher-Entwickler weitgehend heraus. Deshalb hat Rancher sich viel von der Einfachheit bewahrt, für die seine Fans es seit Jahren lieben. Das bedeutet auch: Wer heute mit Kubernetes starten will, findet in Rancher dafür einen Weg mit niedriger Einstiegshürde.

Dennoch ist auch ein Rancher-Setup kein Selbstläufer. Verschiedene Faktoren sind schon im Hinblick auf die Hardware zu beachten. Insbesondere die Menge der nötigen Maschinen und deren Dimensionierung verdient Beachtung. Steht die Hardware betriebsbereit im Rack, geht es mit der Installation einer Kubernetes-Distribution weiter, denn Rancher bildet seine eigene Infrastruktur komplett in Kubernetes ab. Was kompliziert klingt, ist in der Praxis kein Problem, weil Rancher in Form von K3s eine eigene Kubernetes-Rumpfdistribution im Schlepptau hat, die alle benötigten Features liefert.

Dieser Artikel begleitet Sie bei der Einführung von Rancher im eigenen Setup. Los geht es dabei auf der sprichwörtlichen grünen Wiese, das erklärte Ziel ist ein für den produktiven Betrieb nutzbarer Rancher-Cluster. Um dieses Ziel zu erreichen, gilt es aber, vorab ein paar Begriffe aus der Rancher-Welt zu klären, mit denen Administratoren sich regelmäßig konfrontiert sehen.

Ranchers Architektur

Wer sich bereits mit einer der anderen großen Kubernetes-Distributionen befasst hat, ist mit den zentralen Eigenschaften von Rancher anfangs möglicherweise etwas überfordert, denn Rancher funktioniert anders als die meisten Produkte der Konkurrenz. Ein Vergleich macht das schnell deutlich. OpenShift beispielsweise besteht aus einer Management-Ebene, auch Control Plane genannt, die alle zentralen Dienste der Umgebung umfasst. Zwar nutzt auch OpenShift Kubernetes für das eigene Management, doch umfasst ein OpenShift-Setup genau eine Kubernetes-Instanz. Starten Anwender also Container in Kubernetes, so laufen diese im bestehenden Cluster mit und nutzen dessen vorhandene Infrastruktur.

Rancher unterscheidet sich von diesem Ansatz deutlich. Es versteht sich nicht nur als Werkzeug zum Verwalten von Workloads in Kubernetes, sondern auch als Tool zum Steuern und Verwalten von Kubernetes-Umgebungen. Anwendungen laufen daher auch nicht im Kubernetes-Cluster mit, den Rancher für die eigenen Kubernetes-Komponenten benötigt. Stattdessen geht Rancher davon aus, dass jedes Endanwender-Setup eine eigene Kubernetes-Installation ist, die Rancher dann ebenfalls betreibt.

Weil Rancher in diesen Satellitensetups eine Art Maulwurf in Form von Agenten installiert, vermag es auch in diesen sekundären Kubernetes-Clustern Workloads zu steuern. Die Programme, die ein Kubernetes-Cluster in Rancher betreiben soll, laufen mithin niemals in derselben Instanz wie die Rancher-Dienste selbst, sondern immer in einer nachgelagerten, separaten Kubernetes-Umgebung, die Rancher steuert.

Manchem Administrator mögen sich an dieser Stelle die Zehennägel hochrollen, denn auf den ersten Blick wirkt die Rancher-Herangehensweise ungelenk und vor allem nicht sehr ressourceneffektiv. Tatsächlich ist es so, dass die zu jedem Kubernetes-Cluster gehörenden Infrastrukturkomponenten von Kubernetes selbst einen Overhead erzeugen. Weil einzelne Kubernetes-Instanzen in Rancher aber selten Tausende Pods betreiben – dafür würde man eher einzelne K8s-Instanzen betreiben, falls diese nicht zum selben Setup gehören – ist der entstehende Rechenmehraufwand verkraftbar.

Obendrein stehen auf der Haben-Seite eine wirklich saubere Trennung einzelner Anwendungen im Kubernetes-Cluster sowie umfassende Überwachungs- und Alarmierungsmöglichkeiten pro Endanwender-Kubernetes. Darüber hinaus bietet Rancher durch dieses Verfahren eine Option, die in anderen Umgebungen fehlt: Es verwaltet bei Bedarf auch die kommerziellen Kubernetes-Angebote, die sich beispielsweise in AWS, Azure oder Google Cloud finden.

Hardware beschaffen

Hat ein Unternehmen sich für Rancher entschieden, steht zunächst dessen grundlegendes Deployment auf dem Plan. Dafür braucht es Hardware. Zwar lässt sich ein Rancher auch vollständig virtualisiert betreiben, und prinzipiell spricht auch nichts gegen diese Herangehensweise. Wenn auf bestimmten Knoten aber neben den Kubernetes-Komponenten für Rancher auch noch fremder Workload komplett anderer Anwendungen läuft, können Ressourcenengpässe drohen.

Am wohlsten fühlt Rancher sich, wie jede andere Anwendung auch, auf eigener Hardware. Weil das Setup in diesem Beispiel möglichst realistisch ein Rancher in einer echten, produktiven Umgebung wiederspiegeln soll, geht es ebenfalls von eigener Hardware für Rancher aus. Um Hochverfügbarkeit zu erreichen, benötigen Sie zwei Server, die jeweils 128 Gigabyte RAM und mindestens 32 VCPUs mitbringen müssen. Was der Hersteller in diesem Kontext mit VCPUs meint, geht aus der Dokumentation allerdings nicht zweifelsfrei hervor.

Sie dürfen aber guten Gewissens davon ausgehen, dass ein aktueller Xeon mit 24 physischen Kernen (also 48 Threads) für den Betrieb der meisten Rancher-Setups ausreicht. Rancher selbst gibt an, dass eine Maschine dieser Dimension 2000 Cluster und bis zu 20 000 Compute-Knoten sinnvoll betreiben kann. Daran ändert auch nichts, dass die zu Rancher im Hintergrund gehörende Datenbank zwei Kerne sowie 4 GByte RAM für sich beansprucht. Für die Datenbank sind eher IOPS-Werte wichtig; die Systeme sollten bei den genannten Servern idealerweise also auf flottem Flash-Speicher liegen.

Hinzu kommen in einem normalen Setup mindestens zwei Systeme für die Worker-Nodes, also die Hosts, auf denen die Kubernetes-Cluster der Anwender später laufen. Die Dokumentation nennt diese abwechselnd Nodes, Compute Nodes oder Target Nodes, meint in allen Fällen aber dieselben Server. Der Fantasie in Sachen Hardware sind hier kaum Grenzen gesetzt, allzu schmalbrüstig sollten die System aber nicht sein. Zwar benötigen Container anders als ihre Kollegen von der Voll- und Paravirtualisierung keine CPU-Zeit, um eine eigene VCPU und ein eigenes Linux zu betreiben. Genug RAM sollten die Container mit ihren Anwendungen aber trotzdem haben. Dimensionieren Sie die Zielknoten ähnlich wie er einen Node für den Betrieb mit KVM, machen Sie im Normalfall nichts falsch.

Anders als bei den Knoten für die Rancher-Komponenten sollten Sie bei den Compute-Knoten allerdings auf die lokalen Speichermedien der Systeme achten, denn dort lagern im laufenden Betrieb ja die Container. Mit einem schnellen aber kleinen Laufwerk auf NVMe-Basis gerät die Installation also womöglich ins Trudeln. Stellen Sie hier ein paar Gigabyte zur Verfügung, bleiben Sie in den meisten Fällen auf der sicheren Seite.

Gretchenfrage

Damit auf einem System überhaupt Rancher-Dienste laufen können, ist ein Linux dort freilich absolute Grundvoraussetzung. Das zwingt Sie dazu, sich für den Betrieb mit Rancher für eine spezifische Distribution zu entscheiden. Oft dürfte die Versuchung groß sein, zu verwenden, was Sie aus eigener Erfahrung ohnehin kennen. Indem Sie so vorgehen, vertun Sie aber möglicherweise eine große Gelegenheit, denn Rancher bringt seine Komponenten nicht etwa in Form von klassischen Softwarepaketen mit: Auch Rancher selbst ist vollständig in Container verpackt.

Das bedeutet im Umkehrschluss, dass jede für den Betrieb von Containern per Docker oder Podman geeignete Distribution auch für Rancher infrage kommt. Aus Sicht des Administrators gibt es daher keinen Grund, sich ein komplettes Linux ans Bein zu hängen – eine Mikrodistribution wie etwa CoreOS (Abbildung 1) genügt völlig. Alternativ kommt Flatcar Linux infrage, mit dem das Linux-Magazin sich in der Vergangenheit bereits ausführlich beschäftigt hat [1]. Ubuntu Core ist eine weitere Option. Rancher hatte in der Vergangenheit sogar ein eigenes Mini-Linux namens RancherOS, doch das wird mittlerweile nicht mehr offiziell unterstützt.

Abbildung 1: Für Rancher müssen die Zielsystemen nicht mit einer vollständigen Linux-Distribution ausgestattet sein. CoreOS oder Flatcar Linux reichen völlig aus, um Container-Workloads zu betreiben. Quelle: Red Hat

Können Sie sich nicht zu einer Mikrodistribution durchringen, fahren Sie auch mit den üblichen Verdächtigen gut. Hier sollten Sie allerdings von Anfang an darauf achten, das System so schlank wie möglich auszurollen. Obendrein bietet die Einführung von Rancher eine gute Gelegenheit, sich um das Thema Automation zu kümmern: Kickstart-Regeln für AlmaLinux oder Rocket Linux lassen sich schnell erstellen und sparen gerade beim späteren Skalieren der Plattform in die Breite viel Arbeit. Zusätzlich sollten Sie von Anfang an darauf achten, die Systemkonfiguration auf den einzelnen Servern so weit wie möglich zu automatisieren.

Hier wird klar: Ein sinnvoll geplantes Rancher-Setup bedarf bereits einiger Arbeit, bevor es an den Start geht. Die Mühe zahlt sich später aber aus, denn das Erweitern des Clusters gelingt dann schnell und unkompliziert.

Mit Rancher loslegen

Gegeben seien im Beispiel also vier Server, auf denen Ubuntu 20.04 LTS zum Einsatz kommt. Weil Podman vorrangig eine Red-Hat-Erfindung ist, spricht unter Ubuntu nichts dagegen, weiter auf Docker als Container-Laufzeitumgebung zu setzen. Entsprechend sind in der Konfiguration der Systeme die Community-Repositories von Docker aktiviert und die für Docker notwendigen Pakete installiert. In diesem Zustand sind die Systeme bereit für die Rancher-Installation.

Begrifflichkeiten

Wie bei fast jeder Lösung aus dem Cloud-Native-Dunstkreis haben sich auch bei Rancher mit der Zeit Begriffe herausgebildet, die im Rancher-Universum eine eindeutige Bedeutung haben. Vor der Arbeit mit Rancher sollte man die wichtigsten Begriffe kennen. Ist etwa vom Rancher-Server die Rede, bezeichnet das ein System, auf dem alle Komponenten von Rancher für das Management und die Provisionierung von Kubernetes-Clustern beheimatet sind. Wichtig: Von diesen Rancher-Servern gibt es mindestens einen, doch bietet Rancher auf der Ebene seiner Verwaltung auch Skalierbarkeit in die Breite. Die Anzahl der maximalen Rancher-Server pro Installation ist mithin praktisch unbeschränkt.

Ebenso wichtig im Rancher-Kontext ist K3s. Dabei handelt es sich um eine minimale Kubernetes-Version, die die Rancher-Entwickler selbst pflegen und die ausschließlich die für den Betrieb von Rancher notwendigen Komponenten enthält. Zur Erinnerung: Auch Rancher rollt sich selbst als Kubernetes-Cluster aus. K3s bietet dafür die Grundlage, und zwar eine deutlich schlankere als etwa OpenShift.

K3s ist übrigens nicht die einzige Distribution von Kubernetes, mit der Rancher funktioniert. Regelmäßig stößt man auch auf RKE, die Rancher Kubernetes Engine. Auch diese K8s-Distribution stammt direkt von den Rancher-Entwicklern, ist allerdings bereits älter als K3s. Das etwas modernere K3s gilt mithin als die empfohlene Standarddistribution für neue Setups. Zusätzlich gibt es noch RKE2, eine Weiterentwicklung von RKE, die den Fokus auf das Thema Sicherheit legt und für spezielle Einsatzbereiche konzipiert ist, etwa für Behörden.

Infrastruktur erstellen

Der erste Schritt auf dem Weg hin zu einem lauffähigen Rancher ist die Installation von K3s. Das Beispiel geht im Folgenden davon aus, dass dem Setup eine MariaDB- oder MySQL-Datenbank zur Verfügung steht, in der Rancher seine Metadaten ablegen kann. Die kann wahlweise auf denselben Servern wie Rancher laufen, es kommt aber auch eine externe Datenbank auf eigener Hardware infrage. Achten Sie unbedingt darauf, dass die besagte Datenbank hochverfügbar abzusichern: Ohne seine Metadaten ist Rancher mehr oder weniger nutzlos. MariaDB oder MySQL müssen also zuverlässig laufen.

Weil auch die Server-Komponenten von Rancher im Beispiel redundant ausgelegt sein sollen, brauchen Sie zudem einen Load Balancer (Abbildung 2). Der lauscht idealerweise unter der Adresse, unter der später Rancher erreichbar sein soll, auf eingehende Verbindungen und leitet sie an die beiden Rancher-Hosts im Beispiel weiter. Infrage kommt sowohl ein Load Balancer auf der Protokollebene 4 als auch einer auf der Protokollebene 7.

Abbildung 2: Rancher benötigt einen Load Balancer zum Beispiel auf Basis von Nginx, um das Setup hochverfügbar zu machen. Ein Layer-4-Balancer ist für Einsteiger die beste Option. Quelle: Nginx

Wir gehen hier davon aus, dass ein Layer-4-Load-Balancer zum Einsatz kommt, was gerade im Hinblick auf die späteren SSL-Fähigkeiten von Rancher das Setup etwas erleichtert. Ein Layer-7-Gerät böte zwar in der Theorie mehr Konfigurationsmöglichkeiten, doch müssten Sie ihn so konfigurieren, dass er das SSL-Management übernimmt. Im Falle eines Layer-4-Load Balancers erledigt Rancher das hingegen selbst; hierfür rollt es eine Instanz von Traefik [2] aus.

So oder so gilt freilich auch für den Load Balancer, dass er hochverfügbar sein muss. Ansonsten würde sein Ausfall dazu führen, dass Rancher selbst und seine verwalteten Kubernetes-Cluster zwar noch laufen, von außen aber nicht mehr erreichbar wären. Apropos Erreichbarkeit: Der für Rancher vorgesehene DNS-Eintrag sollte zeitgleich mit dem Setup des Load Balancers im Zonen-File der jeweiligen Domäne landen, ansonsten kann die eigentliche Installation von Rancher nicht beginnen.

Zu guter Letzt steht noch eine Komponente auf dem Plan, die heute eigentlich eine Selbstverständlichkeit sein sollte, aber das längst nicht ist: Auf jedem System der Installation sollte die Uhrzeit stimmen. Das lässt sich bei den Distributionen aktuell wahlweise per klassischem NTP oder mittels Chronyd realisieren. So oder so: Eine der beiden Komponenten sollte eingerichtet sein und Zugriff auf einen NTP-Server haben, um die Systemzeit richtig einzustellen.

K3s ausrollen

Die K3s-Autoren machen es denkbar einfach, ihre Software auf das eigene System zu bringen. Dazu genügt es, auf jeder als Rancher-Server vorgesehenen Maschine den Befehl aus der ersten Zeile von Listing 1 auszuführen. Dabei ersetzen Sie »User«, »Passwort«, »Host« und »Datenbank« durch die tatsächlichen Zugangsdaten der MySQL-Datenbank. Unter der Annehme, dass der Benutzername rancher, das Passwort »geheim« und der Datenbankname »rancher« lauten, sieht das Kommando so aus wie in der zweiten Zeile des Listings.

$ curl -sfL https://get.k3s.io | sh -s - server --datastore-endpoint="mysql://User:Passwort@tcp(Host:3306)/Datenbank"
$ curl -sfL https://get.k3s.io | sh -s - server --datastore-endpoint="mysql://rancher:geheim@tcp(10.42.0.1:3306)/rancher"

Der beschriebene Befehl funktioniert freilich nur, wenn das System unmittelbaren Zugriff auf das Internet hat. Das ist für Rancher zwar nicht zwingend nötig, denn die Software lässt sich auch über einen Proxy-Server oder ganz ohne Netzanbindung im Airgap-Modus betreiben. Die Beschreibung dieser Installationsvarianten würde den Rahmen jedoch sprengen, sodass wir es beim Verweis auf die Rancher-Dokumentation belassen.

K3s überprüfen

Auf allen künftigen Rancher-Servern sollte nach dem erfolgreichen Aufruf des Installationsbefehls das Kommando »sudo k3s kubectl get nodes« eine Liste aller Rancher-Server im Setup liefern. Wenn in der Liste wie im Beispiel beide Maschinen zu sehen sind, hat das K3s-Setup funktioniert.

Das Werkzeug K3s ist allerdings ein K3s-spezifisches Werkzeug. Es wäre wünschenswert, an den K3s-Cluster auch mit dem Standardwerkzeug Kubectl heranzukommen. Dazu hat K3s wärend der Installation die Datei »/etc/rancher/k3s/k3s.yaml« angelegt, die jeder ausführende Nutzer nach »~/.kube/config« kopieren sollte. Zuvor muss man sie aber noch anpassen, denn der anzusteuernde Host in der Datei steht ab Werk auf »localhost«.

Ersetzen Sie in der YAML-Datei beim Eintrag »server« diesen Wert durch den DNS-Namen, der auf den zuvor erwähnten Load Balancer zeigt. Im Anschluss sollte der Befehl »kubectl get pods –all-namespaces« funktionieren. Klappt das, ist K3s bereit für die eigentliche Rancher-Installation.

Cert-manager installieren

Weil Rancher seine SSL-Zertifikate im Beispiel automatisch per Let’s Encrypt beziehen soll, ist auch die Installation von Cert-manager nötig. Mehrere Befehle führen zum Erfolg: Der Befehl aus der ersten Zeile aus Listing 2 installiert in der lokalen K3s-Instanz die für Cert-manager notwendigen Custom Resource Definitions, der aus der zweiten fügt der K3s-Instanz das Helm-Verzeichnis für Cert-manager hinzu.

Das Kommando aus Zeile 3 aktualisiert die lokalen Metadaten aller konfigurierten Helm-Verzeichnisse, bevor der Befehl aus Zeile 4 Cert-manager in die lokale K3s-Installation holt. Klappt alles, zeigt der Aufruf aus der letzten Zeile die laufenden Container für den Cert-manager an.

# kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.5.1/cert-manager.crds.yaml
# helm repo add jetstack https://charts.jetstack.io
# helm repo update
# helm install cert-manager jetstack/cert-manager --namespace cert-manager --create-namespace --version v1.5.1
# kubectl get pods --namespace cert-manager

Rancher installieren

Auch ihr Produkt verteilen die Rancher-Entwickler als Helm-Chart. Zur Erinnerung: Der Paketmanager Helm (Abbildung 3) für Kubernetes erlaubt, Metadaten und Images im standardisierten Format auszuliefern. Wie die normalen Pakete der Distributionen lassen sich auch Helm-Charts aus unterschiedlichen Verzeichnissen beziehen.

Abbildung 3: Helm ist ein Paketmanager für Kubernetes und funktioniert ähnlich wie die etablierten Paketmanager für Rpm und Dpkg. Er bündelt Image-Metadaten und Images und macht sie als Ganzes herunterladbar.

Für Rancher fügen Sie Ihrer K3s-Installation zunächst das Helm-Verzeichnis des Rancher-Projekts hinzu (Listing 3, erste Zeile). Dann legen Sie in K3s einen Namespace an, innerhalb dessen alle Rancher-Dienste laufen (Zeile 2) und aktualisieren danach erneut die Metadaten der verfügbaren Helm-Charts (Zeile 3). Der Befehl aus Zeile 4 erschafft einen laufenden Rancher-Cluster, wobei Sie »Host« und »E-Mail« durch die korrekten Werte ersetzen müssen.

# helm repo add rancher-latest https://releases.rancher.com/server-charts/stable
# kubectl create namespace cattle-system
# helm repo update
# helm install rancher rancher-latest/rancher --namespace cattle-system --set hostname=Host --set replicas=3 --set ingress.tls.source=letsEncrypt --set letsEncrypt.email=E-Mail --set letsEncrypt.ingress.class=nginx
# kubectl -n cattle-system rollout status deploy/rancher
# kubectl -n cattle-system get deploy rancher
# kubectl get secret --namespace cattle-system bootstrap-secret -o go-template='{{ .data.bootstrapPassword|base64decode}}{{ "\n" }}'
# curl -sfL https://get.k3s.io | K3S_URL=https://Rancher-Hostname:6443 K3S_TOKEN=Token sh --

Mittels des Kommandos aus Zeile 5 lässt sich während des Vorgangs, der durchaus einige Zeit in Anspruch nehmen kann, der Fortschritt anzeigen. Am Ende sollte der Befehl aus Zeile 6 ein fertiges Deployment mit drei verfügbaren Instanzen anzeigen; die Rancher-Installation ist damit abgeschlossen.

Öffnen Sie nun die URL, die die Adresse des Load Balancers enthält, landen Sie automatisch auf der Login-Page der Installation. Die Benutzerdaten hat Rancher während des Deployments auf der Kommandozeile angezeigt. Beim ersten Login im Webinterface zwingt es Sie allerdings dazu, sie zu ändern. Konnten Sie während der Installation das Passwort nicht mitschreiben, dann fordern Sie es mittels des Kommandos aus der Zeile 7 von Listing 3 erneut an.

Knoten hinzufügen

Momentan existiert zwar ein nutzbarer Rancher-Cluster, doch könnten Sie darauf noch keine Workloads ausrollen: Es fehlen die Nodes, also die Systeme, die die Kubernetes-Cluster der Endanwendungen betreiben. Das Problem lässt sich jedoch schnell lösen. In Sachen Vorbereitung gilt für die Nodes nämlich dasselbe wie für die Rancher-Server, lediglich eine Datenbank ist hier nicht notwendig. NTP jedoch muss ebenfalls aktiv sein.

Sind alle Voraussetzungen erfüllt, genügt der Befehl aus der letzten Zeile von Listing 3. Dabei ersetzem Sie »Rancher-Hostname« durch den am Load Balancer anliegenden Host-Namen. Der Inhalt, den Sie bei »K3S_TOKEN« angeben müssen, finden Sie auf den Servern in der Datei »/var/lib/rancher/k3s/server/node-token«.

Rancher nutzen

Unmittelbar im Anschluss an diese Schritte lassen sich erste Workloads in Rancher ausrollen. Auch der zu Rancher gehörende Marketplace ist anschließend über das Web-UI zu erreichen. Hier stehen fertig konfigurierte und für Rancher optimierte Anwendungen zur Verfügung, die ebenfalls mittels Helm-Charts den Weg in die Installation finden.

Damit sind die Eigenschaften von Rancher aber noch lange nicht ausgereizt. Sobald die ersten Anwendungen als Dienst in Rancher ausgerollt sind, können Sie über den Menüpunkt Monitoring eine Überwachung dafür einrichten. Das umfasst auch die Alarmierung anhand verschiedener Parameter. Kommt Ihnen dabei die Kombination aus Komponenten aus dem Kontext der Cloud-native-Umgebungen bekannt vor, sind auf der richtigen Spur, denn Rancher implementiert sein Monitoring nicht selbst. Es setzt stattdessen im Hintergrund auf das Gespann aus Prometheus (Abbildung 4), seinem Alert-Manager und der GUI-Komponente Grafana (Abbildung 5).

Abbildung 4: Prometheus ist ein ausgesprochen leistungsstarkes Werkzeug zum Sammeln von Metrikdaten. Es werkelt bei Rancher unter der Haube implizit mit, um Admins mit Daten aus Rancher und den betriebenen Endanwender-Setups zu versorgen. Quelle: Alex Eillis

Abbildung 5: Das Gespann aus Prometheus, seinem Alert-Manager und Grafana steht auch in Rancher zur Verfügung. Mit entsprechender Konfiguration durch Rancher versehen hilft es dabei, Container-Workloads zu überwachen. Quelle: Grafana

Fazit

Rancher stellt zwar einige Anforderungen im Hinblick auf die Infrastruktur, die es vor Ort erwartet. Einmal ausgerollt entpuppt es sich jedoch als ausgesprochen leistungsfähiges Werkzeug für den Betrieb von Kubernetes-Workloads. Dabei erweist sich das Setup als intuitiv und vergleichsweise leichtgängig. Möchten Sie Kubernetes anschaffen, sollten Sie Rancher also in die Evaluierung einschließen. (jcb/jlu)