fb
WSO2 Identity Server 5 Minuten

Mit Kubernetes Dashboard UI starten

Thijs_Volders.png
Thijs Volders
Strategic Technology Officer
Starting with Kubernetes dashboard UI
Scrollen

Ich bin auf ein seltsames Problem gestoßen, bei dem ich meinen WSO2 Identity Server Docker-Container nicht öffnen konnte, da einer der dafür vorgesehenen Ports auf meinem System aktiv war. In diesem Blog zeige ich Ihnen das Problem und die Lösung mit Kubernetes Dashboard UI.

Als ich den IS-Container gestartet habe, bekam ich eine Fehlermeldung, dass ein Bind-Port bereits in Gebrauch sei, und zwar der 9443 admin-console port. Ich griff sofort zu meinem Terminal und fragte das (Mac)OS, welcher Prozess diesen Port beansprucht.

sudo lsof -n -i4TCP:9443 | grep LISTEN

Das Ergebnis war… nichts. Das ist seltsam, ich habe das noch nie gesehen.

Kubernetes-Cluster

Ich habe festgestellt, dass ich vor einiger Zeit eine Installation auf meinem lokalen Kubernetes-Cluster erstellt hatte. Möglicherweise lief dieser noch und hat somit den Port genutzt. Ein kurzes Deaktivieren meines lokalen Kubernetes-Clusters ergab, dass ich den WSO2 Identity Server-Container erfolgreich starten konnte. Offenbar hatte Kubernetes den Port doch beansprucht.

Das Deaktivieren des lokalen Kubernetes-Clusters war ein Workaround, aber keine Lösung, und deshalb habe ich den Kubernetes-Cluster erneut gestartet und begonnen, den schuldigen Einsatz oder Dienst zu finden, der diesen Port beansprucht.

Nachdem ich den Cluster erneut gestartet hatte, führte ich ein

kubectl get deployments -all-namespaces=true

durch, was mir zeigte, dass es einige Deployments gab, die die Verwendung dieses bestimmten Ports festgelegt hatten. Nachdem ich mehrere Befehle ausgeführt hatte, um festzustellen, welcher Dienst den benötigten Port tatsächlich in Anspruch nahm, entfernte ich das Deployment schließlich ganz, da es ohnehin veraltet war.

Die Ausführung von kubectl-Befehlen kann für viele ein wenig abschreckend sein, und eine Benutzeroberfläche zu haben, mit der man die gesuchten Informationen findet, kann sehr nützlich sein.

Für Docker gibt es die bekannte Benutzeroberfläche Portainer und auch für Kubernetes existiert eine Alternative. Sie heißt Kubernetes-Dashboard und ist als importierbare Kubernetes-Konfiguration verfügbar. Um Zugang zum Dashboard zu erhalten, müssen mehrere Aktionen durchgeführt werden.

Der Start des Dashboards selbst ist so einfach wie das Hinzufügen der Dashboard-Konfiguration zu Ihrem Cluster mit

kubectl apply -f

https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-beta1/aio/deploy/recommended.yaml

Dies fügt ein Deployment und einen Dienst zum kubernetes-dashboard-Namensraum im Kubernetes-Cluster hinzu.

Starten Sie dann den Kubernetes-Proxy, um auf die Benutzeroberfläche zugreifen zu können.

kubectl proxy

Voilà, das Dashboard sollte verfügbar sein unter: http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/

Wenn Sie das Dashboard öffnen, wird ein Anmeldebildschirm angezeigt.  In diesem Bildschirm muss eine kubeconfig-Datei oder ein Zugriffstoken angegeben werden.

Token

Für die erste Option, ein neues Konto für die Anmeldung am Kubernetes-Dashboard einzurichten, muss man entweder ein Dienstkonto wiederverwenden oder erstellen, es mit einer Cluster-Rollenbindung versehen und dann seinen geheimen Token-Wert finden. Den Token-Wert können Sie dann in das Passwort-Feld des Anmeldebildschirms einfügen und die Anmeldung sollte erfolgreich sein.

Um dieses Dienstkonto, nennen wir es dashuser, zu erstellen, kann der folgende Befehl verwendet werden. Der Einfachheit halber wird das Konto im Standard-Namespace erstellt.

kubectl create serviceaccount dashuser -n default

Um die Benutzeroberfläche optimal nutzen zu können, ist es am einfachsten, ein Konto zu haben, das in der Lage ist, Administrator des Clusters zu sein und somit dem dashuser einen root-ähnlichen Zugriff zu geben.

Dies ist möglich, indem man dem Dash-Benutzer ein clusterrolebinding von cluster-admin zuweist.

kubectl create clusterrolebinding dashboard-admin -n default
--clusterrole=cluster-admin --serviceaccount=default:dashuser

Dadurch wird das Clusterrolebinding mit dem Namen „dashboard-admin“ im Standard-Namensraum erstellt, dem die Clusterrolle „cluster-admin“ zugewiesen wird, und die Verbindung wird auf das Dienstkonto „default:dashuser“ übertragen.

Dies sollte ausreichend sein, um mit diesem Benutzer auf das Dashboard zuzugreifen.

Um auf das Dashboard zuzugreifen, wird das Zugriffs-Token dieses Dienstkontos benötigt. Dieses Zugriffs-Token existiert im Secret-Store des Dashusers. Dieser wurde beim Anlegen des Benutzers automatisch generiert und Sie müssen ihn abrufen, um sich anzumelden.

Um den geheimen Namen für das Dienstkonto zu ermitteln, rufen Sie dessen Informationen ab

kubectl get serviceaccount dashuser -o json

Das wird es uns zeigen (abgekürzt)

...
"secrets": [
{
"name": "dashuser-token-np6c6"
}
]
...

Um den Wert dieses Geheimnisses abzurufen, verwenden Sie dann diesen Namen als Parameter im folgenden Befehl:

kubectl get secret dashuser-token-np6c6 -o json

Die Ausgabe sollte ein Datenfeld mit einem Token-Element enthalten, das den base64-kodierten Wert des erforderlichen Tokens enthält. Diesen Wert kopieren, base64-dekodieren und schon ist der Wert da, der im Dashboard-Anmeldebildschirm angegeben werden kann.

Das folgende Kommando ist ein einfacher dynamischer Einzeiler, der die drei obigen Kommandos in einer einzigen Anweisung zusammenfasst:

kubectl get secret $(kubectl get serviceaccount dashuser -o

Schon haben Sie das Token für die Anmeldung am Dashboard. Den Wert kopieren und in das Eingabefeld auf dem Dashboard in Ihrem Browser einfügen und die Anmeldung sollte erfolgreich sein.

Für jede weitere Anmeldung bei diesem Dashboard müssen Sie den letzten Befehl erneut ausführen, um den Token-Wert abzurufen und ihn in das Anmeldefeld einzufügen.

Kubeconfig

Die andere Möglichkeit ist, eine kubeconfig-Datei zu erstellen, die die Informationen zur Anmeldung am Dashboard enthält. Zum Erstellen einer kubeconfig-Datei müssen mehrere der oben genannten Befehle wiederverwendet und die Ergebnisse in eine json-Struktur eingepasst werden, die dann in der kubeconfig-Datei abgelegt wird.

Bei Stackoverflow gibt es einen sehr wertvollen Ausschnitt zur Erstellung dieser kubeconfig-Datei aus einem einfachen Shell-Skript. Diesen habe ich leicht abgeändert, um ihn für meinen Geschmack etwas benutzerfreundlicher zu gestalten. In dieser Fassung können Sie den Namen des Dienstkontos anstelle des Token-Namens angeben.

# your server name goes here
server=https://localhost:8443
# the name of the service account goes here
name=dashuser

# Enable this line if you’ve use a custom namespace for the user. This will switch the current namespace to the designated one. 
#kubectl config set-context $(kubectl config current-context) --namespace=default

secretname=$(kubectl get serviceaccount $name -o jsonpath="{.secrets[0].name}")
ca=$(kubectl get secret/$secretname -o jsonpath='{.data.ca.crt}' )
token=$(kubectl get secret/$secretname -o jsonpath='{.data.token}' | base64 --decode)
#namespace=$(kubectl get secret/$secretname -o jsonpath='{.data.namespace}' | base64 --decode)

echo "
apiVersion: v1
kind: Config
clusters:
- name: default-cluster
 cluster:
certificate-authority-data: ${ca}
server: ${server}
contexts:
- name: default-context
 context:
 cluster: default-cluster
 namespace: default
 user: default-user
current-context: default-context
users:
- name: default-user
 user:
 token: ${token}
" > sa.kubeconfig

Dieses Skript generiert eine Datei namens sa.kubeconfig im aktuellen Ordner. Wechseln Sie zurück zum Browser und wählen Sie die Option Kubeconfig und geben Sie diese Datei zur Anmeldung an.

Wenn Sie einen Fehler wie diesen erhalten
image-11

dann ist die kubeconfig-Datei unvollständig. Prüfen Sie, ob das obige Skript mit dem richtigen Service-Kontonamen versehen wurde und ob der richtige Namensbereich verwendet wurde, um das Service-Konto und seine geheimen Informationen zu finden.

Dashboard

Das Dashboard gibt einen Überblick über die komplette Clusterkonfiguration. Dort sind Informationen wie Namensbereiche, Bereitstellungen, Dienste und Replikat-Sets sichtbar.

Es ist ein nützliches Tool, das Sie in Ihrem Werkzeugkasten haben sollten, wenn Sie Kubernetes nutzen, da es einen schnellen Überblick über die Komponenten im Cluster ermöglicht und auch einige Verwaltungsaktionen durchführt.

image-12

Haben Sie noch Fragen? Zögern Sie nicht, unten einen Kommentar zu hinterlassen.