Mandantenfähige Observability mit vCluster: Metriken und Logs

Hinweis: Dieser Beitrag wurde aus dem Englischen übersetzt. Fachbegriffe, Code und Befehle wurden bewusst im Original belassen.

Dieser Artikel baut auf unserer früheren Betrachtung der zentralen Metrikerfassung mit vCluster auf und erweitert den Observability-Stack um zentrales Logging mit Promtail und Loki.

Warum Mandantenfähigkeit nötig ist

Als Platform Engineers bauen wir gemeinsam genutzte Plattformen für mehrere Teams. Eine zentrale Entscheidung ist die Trennung der Mandanten, die häufig auf eine Aufteilung nach Namespaces mit eingeschränktem RBAC hinausläuft. Dieses Muster ist einfach umzusetzen und verursacht wenig administrativen und infrastrukturellen Aufwand. Der Preis dafür ist eine schwache Isolation und ein gemeinsamer Blast Radius, da sich alle Mandanten denselben API-Server teilen. Die Nachteile eines gemeinsamen API-Servers treten besonders deutlich zutage, wenn Teams auf Kubernetes-Operatoren wie den Prometheus Operator oder Logging-Operatoren setzen. In einem Modell mit gemeinsamem API-Server lassen sich Operatoren nur schwer isolieren, da sie typischerweise cluster-weite Ressourcen wie CRDs installieren und die Hoheit über bestimmte APIs beanspruchen. Verschiedene Teams können daher Operator-Versionen nicht unabhängig voneinander wählen. Benötigt etwa Team A den Prometheus Operator v4, während Team B auf v5 umsteigen möchte, erzwingt der gemeinsame API-Server eine einheitliche Version für alle Mandanten. Diese enge Kopplung schränkt die Autonomie der Teams ein und erschwert unabhängige Upgrade-Zyklen – ein weiteres Beispiel für die Grenzen namespace-basierter Mandantenfähigkeit. Diesen Nachteilen ließe sich begegnen, indem man jedem Mandanten einen eigenen Cluster gibt, doch das führt zu erheblichem Verwaltungsaufwand und häufig zu ungenutzten Ressourcen. Plattformteams wünschen sich wenig administrativen Aufwand und geringe Komplexität, Nutzer hingegen eine starke Trennung mit isolierten Quotas und Policies. Daraus entsteht meist ein Zielkonflikt: Wir suchen ein Modell, das sich für den Mandanten wie ein Cluster anfühlt und für das Plattformteam so handhabbar bleibt wie Namespaces.

Die Lücke mit vClusters schließen

vCluster stellt virtuelle Kubernetes-Cluster bereit, die innerhalb eines Host-Clusters betrieben werden und jeweils über eine eigene virtuelle Control Plane verfügen. Das bietet mehr Autonomie und Isolation als eine namespace-basierte Trennung und erfordert zugleich weniger Aufwand, als jedem Mandanten einen vollständigen Cluster zu widmen. In diesem Artikel konzentrieren wir uns auf vCluster Private Nodes, die über dedizierte Worker Nodes die Mandanten auch auf Infrastrukturebene isolieren.

Warum zentrale Observability nötig ist

In einer mandantenfähigen Umgebung wird die Erfassung von Metriken und Logs zur Aufgabe der Plattform. Für jeden Mandanten einen eigenen Stack auszurollen, erhöht die Komplexität schnell bei geringem Nutzen, und denselben Metrik- und Logging-Stack je Mandant zu betreiben, ist ressourcenintensiv. Wird dieser Stack im Host-Cluster zentralisiert, bleibt es einfach, der Ressourcenverbrauch sinkt und der Observability-Fußabdruck wächst nicht mit der Zahl der Mandanten. Auch Debugging und Upgrades werden einfacher, da es einen einzigen zentralen Kontrollpunkt gibt. Deshalb ist dieses Muster für Plattformteams oft die erste Wahl. vCluster fügt sich hier natürlich ein: Während Mandanten ihre eigenen virtuellen Cluster betreiben, laufen die Workloads letztlich auf einem gemeinsamen Satz von Nodes im Host-Cluster.

Ziel dieses Artikels ist es, mögliche Umsetzungen für die zentrale Erfassung von Metriken und Logs mit vCluster Private Nodes aufzuzeigen.

Setup

Für dieses Setup kommt AWS EKS zum Einsatz; eine vCluster-Free- oder -Enterprise-Lizenz wird benötigt. Die Befehle zum Nachvollziehen sowie der Terraform-Code zur Erstellung des Clusters finden sich unter commands.md im GitHub-Repository.

Sobald das EKS-Fundament steht, stellt die Plattform zwei Mandanten-vClusters bereit (shop1 und shop2). Entscheidend ist dabei, dass jedem vCluster bestimmte EC2-basierte Worker Nodes als Private Nodes zugewiesen werden, sodass sich die Mandanten weder untereinander noch mit dem Host-Cluster Compute teilen. Das verschärft die Isolation auf Infrastrukturebene und vermeidet viele Noisy-Neighbor- und Co-Scheduling-Probleme – bedeutet aber auch, dass der Host-Cluster keinen direkten Zugriff mehr auf die Workload-Objekte der Mandanten hat, um sie zu scrapen.

Metrik-Setup

Damit kommen wir zum zentralen Monitoring: Aus betrieblicher Sicht wollen wir weiterhin einen einzigen kube-prometheus-stack, können uns aber nicht mehr darauf verlassen, dass das Host-Prometheus die Pods der Mandanten direkt findet. Die in diesem Artikel vorgestellte Lösung ist ein Prometheus-Server je Mandant.

Jeder vCluster betreibt ein minimales Prometheus, dessen Aufgabe darin besteht, innerhalb der Private-Node-Umgebung zu scrapen, wo die Pods tatsächlich sichtbar sind. Dieses mandantenspezifische Prometheus ist so konfiguriert, dass es per Remote Write an das zentrale Prometheus im Host-Cluster schreibt. Das Host-Prometheus muss dafür über enableRemoteWriteReceiver: true als Remote-Write-Empfänger aktiviert werden.

Damit diese Weiterleitung möglich ist, ohne den Monitoring-Stack öffentlich zugänglich zu machen, wird der Host-Prometheus-Endpunkt als interner Load Balancer veröffentlicht. Da Host-Cluster und vClusters innerhalb derselben VPC liegen, erreichen die mandantenseitigen Prometheus-Instanzen das Host-Prometheus sicher über private Netzwerkpfade. So bleiben die wesentlichen Plattformvorteile erhalten – ein zentraler Ort für Alerting, Retention und Grafana – während man sich zugleich auf die eingeschränkte Sichtbarkeit einstellt, die Private Nodes mit sich bringen.

Logging-Setup

Das Logging-Setup folgt einem ähnlichen Muster wie die Metriken, ist in der Umsetzung aber etwas einfacher. Loki wird als SingleBinary im Host-Cluster ausgerollt und als interner NLB bereitgestellt, erreichbar für alle vClusters innerhalb derselben VPC. Da es sich um ein zentrales Single-Instance-Setup handelt, wird auth_enabled auf false gesetzt, sodass mandantenspezifische Authentifizierungs-Header entfallen.

Jeder vCluster betreibt ein Promtail-DaemonSet, das Logs aus dem Verzeichnis /var/log/containers des Nodes einsammelt und direkt an die zentrale Loki-Instanz schickt. Beim Einsammeln fügt Promtail jedem Log-Stream ein Label cluster=vcluster-<name> hinzu, was eine saubere Mandantentrennung bei Abfragen in Grafana ermöglicht. Logs von shop1 lassen sich beispielsweise mit {cluster="vcluster-shop1"} filtern und weiter nach Namespace, Anwendung oder Log-Level eingrenzen.

Ein wichtiger Hinweis für den Produktivbetrieb: Loki nutzt in diesem Setup ein emptyDir-Volume, Logs überleben also keinen Pod-Neustart. Für ein Produktiv-Deployment sollte dies durch ein Persistent Volume oder ein Object-Storage-Backend wie S3 ersetzt werden.

Mandantenbezogene Dashboards

Dashboards müssen mandantenbezogen bleiben, damit das Isolationserlebnis erhalten bleibt. In dieser Demo geschieht das bewusst einfach: Namespaces erhalten ein mandantenspezifisches Suffix (etwa -shop1 oder -shop2), und die Grafana-Dashboards werden auf diese Namespaces eingegrenzt. Bei den Logs greift dasselbe Muster – die Trennung zwischen vClusters erfolgt über das von Promtail ergänzte Label cluster. Das Muster ist leicht verständlich und bewährt sich in der Praxis. Das Ergebnis spiegelt das Versprechen des Setups wider: zentrales Prometheus, Loki und Grafana mit mandantengetrennten Sichten – bei gleichzeitiger Anerkennung der Realität von Private Nodes: Erst muss innerhalb jeder Mandantengrenze gesammelt werden, und erst danach lassen sich Metriken und Logs kontrolliert zentral aggregieren.

Die wichtigsten Erkenntnisse

Wir haben untersucht, wie sich die zentrale Erfassung von Metriken und Logs in mandantenfähigen Kubernetes-Plattformen mit vClusters umsetzen lässt. Kubernetes bringt zwar grundlegende Observability-Werkzeuge je Cluster mit, doch diese Stacks für jeden Mandanten unabhängig zu skalieren, wird schnell komplex, ressourcenintensiv und schwer beherrschbar. Werden Metriken und Logs im Host-Cluster zentralisiert, entsteht ein einziger operativer Anlaufpunkt für Prometheus, Loki, Grafana und Alerting, während Mandanten weiterhin mit ihren isolierten virtuellen Clustern arbeiten.

In diesem Artikel haben wir gezeigt, wie Mandanten-Workloads in regulären vClusters automatisch für das Prometheus des Host-Clusters sichtbar sind und wie sich Metriken in Private-Node-Setups über leichtgewichtige Prometheus-Instanzen mit Remote Write an ein zentrales Prometheus sicher je Mandant erfassen lassen. Ebenso haben wir dargestellt, wie sich Logs mit Promtail und Loki zentralisieren lassen – nach demselben Muster: zunächst innerhalb jeder Mandantengrenze sammeln, dann zentral aggregieren, wobei die Mandantentrennung in Grafana über das Label cluster erhalten bleibt.

Diese Muster stellen sicher, dass Platform Engineers einen einzigen Observability-Stack effizient betreiben können, während Mandanten ein isoliertes, clusterartiges Erlebnis behalten.