Das Kubermatic-Virtualisierungs-Dashboard aktivieren

Das Kubermatic Virtualization Dashboard ist die in Version 1.1.0 eingeführte Benutzeroberfläche für Cluster-Administratoren. Es bietet Ihnen einen VM-orientierten Browser – mit Funktionen zum Starten, Stoppen und für die Konsole sowie Ansichten zu Knoten, Datenträgern, Firewalls und Load Balancern – für den Cluster, in dem es sich befindet. Es wird bereitgestellt und synchronisiert durch die kubev das Installationsprogramm selbst, nicht als separates Helm oder Add-on. Die Aktivierung erfolgt über einen Konfigurationsblock und ein erneutes Anwenden.

Dieses Tutorial behandelt das Einschalten, die drei Authentifizierungsmodi sowie das Zugriffsmodell für die Testumgebung und die Produktionsumgebung.

Pro Cluster, nicht clusterübergreifend

Der Anwendungsbereich des Dashboards ist entscheidend: Es zeigt den Cluster an, in dem es installiert ist, nicht die gesamte Flotte. Wenn Sie viele Cluster betreiben und eine einzige clusterübergreifende Bestandsübersicht wünschen, bleibt KKP das richtige Werkzeug – und die beiden ergänzen sich, anstatt sich zu überschneiden. KKP beantwortet die Frage „Welcher Cluster?“, während das Kubermatic Virtualization Dashboard die Frage „Was passiert in diesem Cluster?“ beantwortet.

Wenn Sie nur einen Cluster betreiben, werden Sie KKP vielleicht nie benötigen. Das Dashboard sowie kubectl Das reicht.

Was wird installiert?

Durch die Aktivierung des Dashboards wird Folgendes erstellt:

Ein neuer Namensraum, kubermatic-virtualisierung
Zwei Einsätze: kubev-api-server (kommuniziert im Namen des Benutzers mit der Kubernetes-API) und kubev-Dashboard (eine von Nginx bereitgestellte React-SPA)
Ein Dienst namens kubev-Dashboard auf Port 8080
Das „image-pull“-Passwort, das zum Abrufen der Dashboard-Bilder von quay.io benötigt wird

Beide Pods sind klein. Es gibt keine separate Datenbank – das Dashboard liest und schreibt über dieselbe Kubernetes-API, die Ihre kubectl bereits verwendet, was bedeutet, dass YAML die maßgebliche Quelle bleibt. Die Benutzeroberfläche dient lediglich der Vereinfachung; sollte darin etwas nicht stimmen, kubectl get und kubectl describe bleiben die Ausweichlösung.

Pull-Secret-Vorabprüfung

Die Dashboard-Bilder befinden sich auf quay.io und sind zugangsbeschränkt. Das Installationsprogramm führt vorab eine Überprüfung auf folgende Punkte durch:

KUBEV_USERNAME und KUBEV_PASSWORT Umgebungsvariablen (die gleichen Anmeldedaten für quay.io, die auch an anderer Stelle bei der Installation verwendet werden)
Ein Inline-Element imagePullSecret: einfügen cluster.yaml die eine JSON-Datei namens „docker-config“ enthält

Der Antrag wird abgelehnt, wenn keines von beiden vorhanden ist. Dies ist ein bekanntes Problem – die Fehlersuche nach dem Grund, warum meine Pods nicht abgerufen werden, nachdem anwenden Ein erfolgreicher Start ist schmerzhafter als ein schnelles Scheitern aufgrund fehlender Anmeldedaten, weshalb das Installationsprogramm Letzteres wählt.

Bitte überprüfen Sie dies, bevor Sie beginnen:

echo "${KUBEV_USERNAME:-MISSING}"
test -n "$KUBEV_PASSWORD" && echo "set" || echo "MISSING"

Füge das `Dashboard:` Block

Öffnen Sie Ihre bestehende cluster.yaml und füge ein Dashboard: Block. Die Minimalversion für das Labor (keine Authentifizierung, Zugriff über Portweiterleitung):

dashboard:
  enabled: true
  auth:
    none: {}

Die Minimalversion der Basisauthentifizierung:

dashboard:
  enabled: true
  auth:
    basic: {}     # uses KUBEV_USERNAME / KUBEV_PASSWORD

Die OIDC-Version (Produktionsstandard – funktioniert mit Keycloak, Dex, Okta, Azure AD, Google und allen anderen Diensten, die OIDC unterstützen):

dashboard:
  enabled: true
  dashboardURL: https://kubev.example.com
  auth:
    oidc:
      issuerURL: https://keycloak.example.com/realms/kubev
      clientID: kubev-dashboard
      clientSecret: <generated>
      redirectURL: https://kubev.example.com/oauth/callback

Hinweis Dashboard-URL — Für OIDC benötigt der Emittent ein stabiles Weiterleitungsziel, daher ist dies im Produktivbetrieb nicht optional.

Bewerben

Führen Sie das Installationsprogramm erneut aus:

kubermatic-virtualization apply -f cluster.yaml

Das Installationsprogramm ist deklarativ und selbstheilend – bei einer erneuten Ausführung werden die neuen Dashboard: Block erstellt den Namespace und die Deployments und gleicht sie bei jedem nachfolgenden Apply ab. Es gibt keinen separaten Dashboard installieren Schritt.

Verfolgen Sie die Einführung:

kubectl -n kubermatic-virtualization rollout status deploy/kubev-api-server
kubectl -n kubermatic-virtualization rollout status deploy/kubev-dashboard

Zugriff auf das Labor über Portweiterleitung

Bei einem isolierten Labor-Cluster leiten Sie den Port direkt auf den Dienst weiter:

kubectl port-forward svc/kubev-dashboard -n kubermatic-virtualization 8080:8080

Öffnen http://localhost:8080. Mit auth.none gelangen Sie direkt zur Dashboard-Ansicht. Mit auth.basic Du wirst mit denselben Herausforderungen konfrontiert werden KUBEV_USERNAME / KUBEV_PASSWORT die Sie bei der Installation festgelegt haben.

In der linken Seitenleiste sind die Bedienelemente zusammengefasst:

Dashboard – Kacheln zur Ressourcenübersicht
Rechenleistung – Virtuelle Maschinen, VM-Pools, automatische Skalierung
Infrastruktur – Knoten, Instanztypen
Storage — Datenmengen, Bilder
Netzwerk – VPCs, Subnetze, Load Balancer
Sicherheit – Firewalls, SSH-Schlüssel

Die VM-Detailansicht verfügt über vier Registerkarten: Netzwerken, Festplatten, Überwachung, Konsole. Die Registerkarte „Konsole“ ist dieselbe serielle Konsole, auf die Sie bisher über virtctl-Konsole, eingebettet im Browser.

Zugang zur Produktion

kubectl port-forward ist für eine Testumgebung in Ordnung. Für die Produktion sollte man kubev-Dashboard Dienst mit einem Ingress (TLS-terminiert) oder einem LoadBalancer-Dienst, Punkt dashboardURL: unter der extern erreichbaren URL und verwende auth.oidc mit Ihrem bestehenden Identitätsanbieter. Die Bereitstellung in der Produktionsumgebung wird hier nicht behandelt, aber das Handbuch zum Kubermatic-Virtualisierungsoperator führt Sie durch das gesamte Verfahren.

Wie geht es weiter?

Das Dashboard ist der Einstiegspunkt, den die meisten Betreiber im Alltag nutzen. Dahinter erfolgt jeder Bildschirmzugriff über Lese- und Schreibvorgänge auf dieselbe Kubernetes-API – also kubectl bleibt die diagnostische Ebene, wenn in der Benutzeroberfläche etwas nicht stimmt. Das nächste Tutorial dieser Reihe befasst sich mit GitOps-Installationen, bei denen kubev anwenden wird über eine CI-Pipeline ausgeführt, und das Dashboard dient als vorwiegend leseorientiertes Fenster in einen Cluster, der anhand der Versionskontrolle abgeglichen wird.