Die OpenShift-Konsole ist eine ansprechende GUI, die für den Einsatz innerhalb von OpenShift-Clustern gedacht ist. Sie bietet eine konsolidierte Übersicht über Ressourcen, integrierte Metriken und Alarmierung und ermöglicht es auch, Cluster-Ressourcen über einen Webbrowser zu aktualisieren. Wie der Name schon andeutet, wird die Konsole mit OpenShift als primärem Anwendungsfall entwickelt. Bei meiner Arbeit bei Cloudflight habe ich die OpenShift-Konsole für schnelle Prüfungen und die Visualisierung von Ressourcen wirklich schätzen gelernt, und ich wollte sie für mich selbst einrichten. Das einzige Problem: Ich betreibe zu Hause aus Ressourcengründen k3s. Also machte ich mich auf die Reise zu sehen, ob ich die Konsole in reinem Kubernetes zum Laufen bringen kann.

Voraussetzungen

Wenn ihr auf eurem eigenen Cluster mitmachen möchtet, muss die Authentifizierung auf eurem Cluster korrekt eingerichtet sein. Ich verwende OIDC, also richten wir das hier ein – aber fühlt euch frei, mit anderen Anbietern zu experimentieren.

Die Konsole lokal starten

Glücklicherweise haben die Entwickler der Konsole sehr gute Arbeit geleistet, die Konsole von den anderen OpenShift-Komponenten getrennt zu halten, und bieten sogar eine Anleitung zur lokalen Entwicklung der Konsole gegen einen reinen Kubernetes-Cluster an. Schauen wir uns also den Code an und sehen, ob es funktioniert.

Das Repository stellt uns folgende Anweisungen bereit:

./build.sh
source ./contrib/environment.sh
./bin/bridge

Wenn eure lokale Kubeconfig-Datei korrekt eingerichtet ist, startet das die Konsole unter localhost:9000 ohne Fehler. Wenn ihr jedoch herumklickt, werdet ihr feststellen, dass ihr nicht mit eurem Benutzer eingeloggt seid, sondern als system:serviceaccount:kube-system:default. Der Grund dafür ist in der Datei contrib/environment.sh zu finden. Dieses Skript richtet die Authentifizierung mit dem ersten Service-Account im kube-system-Namespace ein. Das ist offensichtlich nicht das, was wir wollen. Wir möchten, dass sich jeder Benutzer als er selbst einloggt – schauen wir uns also die verfügbaren Authentifizierungsmethoden an.

Authentifizierung

Zum Zeitpunkt des Schreibens unterstützt die Konsole entweder die openshift– oder die oidc-Benutzerauthentifizierungsmethode.

Wenn ihr die Authentifizierung auf einer anderen Ebene durchführt (z. B. über ein VPN-Gateway), könntet ihr die Benutzerauthentifizierung ganz deaktivieren und die service-account– oder bearer-token-Methode verwenden, um Aktionen in der Konsole mit einem vorhandenen Service-Account durchzuführen. Ich möchte, dass sich jeder Benutzer direkt an der Konsole anmeldet, also werde ich die Benutzerauthentifizierung mit der oidc-Strategie einrichten.

Die Konsole kann auf drei Arten konfiguriert werden: eine Konfigurationsdatei, Umgebungsvariablen oder Befehlszeilenargumente. Die Werte werden auch in dieser Reihenfolge angewendet, sodass Befehlszeilenargumente alles andere überschreiben – weshalb ich sie zur lokalen Fehlersuche im Setup verwende. Namen konfigurierbarer Parameter können durch Ausführen von bin/bridge -h gefunden werden.

bin/bridge -k8s-auth oidc -user-auth oidc
#W0501 15:29:54.430483   37685 main.go:213] Flag inactivity-timeout is set to less then 300 seconds and will be ignored!
#W0501 15:29:54.430526   37685 main.go:347] cookies are not secure because base-address is not https!
#F0501 15:29:54.430541   37685 validate.go:50] Invalid flag: base-address, error: value is required

Das hat nicht funktioniert. Das Programm teilt uns fehlende Werte mit, also konfigurieren wir sie entsprechend unserem OIDC-Anbieter:

bin/bridge 
  -k8s-auth oidc -user-auth oidc 
  -user-auth-oidc-client-id=<client-id> 
  -user-auth-oidc-client-secret=<client-secret> 
  -user-auth-oidc-issuer-url=<issuer-url> 
  -base-address http://localhost:9000

Diese Werte können aus eurer API-Server-Konfiguration entnommen werden. Wenn alles korrekt eingerichtet ist (vergesst nicht die Redirect-URI im OIDC-Anbieter), werdet ihr authentifiziert und könnt Aktionen mit eurem eigenen Benutzerkonto durchführen.

Metriken

Der OpenShift-Metrik-Stack ist eine völlig andere Komponente und übernimmt die schwere Arbeit der Überwachung von Workloads in einem Cluster. Wie bei der Konsole könnte er auch in reinem Kubernetes betrieben werden, aber ich habe bereits einen Metrik-Stack mit kube-prometheus eingerichtet. Es ist immer noch möglich, diesen mit der Konsole zu verbinden, erfordert aber etwas mehr Arbeit.

Der relevante Konfigurationsparameter dafür heißt k8s-mode-off-cluster-thanos. Wenn ihr das erste Mal von Thanos hört, keine Angst. Es ist eine Hochverfügbarkeits- und Langzeitspeicherlösung für Prometheus, kann aber durch reines Prometheus für unsere Zwecke ersetzt werden. Wenn ihr Thanos bereits eingerichtet habt, umso besser – ich hatte dafür noch nicht die Zeit.

Wenn die Konsole mit der richtigen Thanos-/Prometheus-URL versorgt wird, seht ihr bereits eure ersten Metriken:

console_metrics_missing.png

Eins von vier! Nicht schlecht. Schauen wir uns an, wie wir diese fehlenden Metriken abrufen können. Durch Klicken auf das Panel werden wir zur Metrik-Abfrage weitergeleitet. Hier wird das Problem offensichtlich.

console_no_datapoints.png

Das sieht für mich wie eine benutzerdefinierte Metrik (auch bekannt als Recording Rule) aus. Aber wo finden wir die Quelle dafür, damit wir sie in unserem Monitoring-Stack wiederverwenden können? Sourcegraph zur Rettung! Durch die Verwendung der Abfrage repo:openshift pod:container_cpu_usage:sum finden wir schnell die Quelle für diese Regeln: prometheus-rule.yaml im cluster-monitoring-operator.

Das Platzieren dieser Regeln in eurer Prometheus-/Thanos-Instanz bleibt als Übung für den Leser.

Danach seht ihr zumindest Speicher- und CPU-Nutzung. Die anderen Metriken in der Konsole hängen teilweise von OpenShift-Features und/oder Metriken unter Standardnamen ab. Sie können ebenfalls mit Recording Rules rekonstruiert werden, aber ich bin auch ohne sie zufrieden.

console_metrics_present.png

Umgang mit dem Zustand

Beim Betrieb der Konsole sind euch möglicherweise Fehler der Form Failed to get user data to handle user setting request: the server could not find the requested resource aufgefallen. Das tritt auf, wenn die Konsole versucht, eure Benutzereinstellungen in einem Konfigurationsordner zu speichern. Zum Speichern von Benutzereinstellungen erwartet die Konsole, dass eine user.openshift.io-Ressource vorhanden ist, die nur in OpenShift-Clustern verfügbar ist. Die einfache Umgehung dafür ist die Angabe von -user-settings-location=localstorage, da dies diesen Schritt überspringt. Vielleicht wird in der Zukunft Unterstützung für Cluster ohne diese Ressource beigesteuert.

Die Konsole deployen

Das Deployen der Konsole ist so einfach wie das Deployen jeder anderen Anwendung. Container-Images sind von quay.io/openshift/origin-console verfügbar. Leider sind nur amd64-Images verfügbar, aber wenn ihr arm-Images benötigt, könnt ihr die Konsole selbst bauen.

Ich werde hier nicht ins Detail gehen, sondern einfach auf mein Konfigurations-Repository verweisen, wenn ihr Inspiration benötigt, wie ihr es auf eurem Cluster einrichten könnt.

Hinweis: Wenn ihr plant, die Konsole innerhalb eures Clusters auszuführen, müsst ihr sie trotzdem so konfigurieren, dass sie den Off-Cluster-Kubernetes-Modus verwendet. Andernfalls wird sie die OpenShift-Standard-Endpunkte anstelle eurer konfigurierten URLs verwenden.

Weitere Anpassungen

Natürlich endet die Anpassung hier nicht. Experimentiert ruhig mit anderen Parametern des bridge-Binaries (insbesondere den Branding-Parametern)! Eine Vielzahl weiterer Integrationen ist möglich (Alertmanager, Grafana, Entwicklerperspektive). Ich werde möglicherweise mehr darüber auf meinem persönlichen Blog schreiben, wenn ich sie zum Laufen bringe.