Integration des Kubernetes Dashboards und der GitLab-Benutzer

Kubernetes Dashboard – ein benutzerfreundliches Tool zur Abrufung aktueller Informationen über den laufenden Cluster und zur minimalen Verwaltung. Man schätzt es noch mehr, wenn der Zugang zu diesen Funktionen nicht nur für Administratoren/DevOps-Ingenieure erforderlich ist, sondern auch für diejenigen, die weniger an die Konsole gewöhnt sind und/oder nicht beabsichtigen, sich mit allen Feinheiten des Umgangs mit kubectl und anderen Tools auseinanderzusetzen. So erging es auch uns: Die Entwickler wollten schnellen Zugang zur Weboberfläche von Kubernetes, und da wir GitLab verwenden, bot sich die Lösung geradezu an.

Warum das?

Direkte Entwickler könnten an einem Tool wie dem K8s Dashboard für Debugging-Aufgaben interessiert sein. Manchmal möchte man Protokolle und Ressourcen einsehen und gelegentlich Pods beenden, Deployments/StatefulSets skalieren oder sogar auf die Konsole der Container zugreifen (solche Anfragen gibt es, für deren Lösung es jedoch auch einen anderen Weg gibt – zum Beispiel über kubectl-debug).

Außerdem gibt es einen psychologischen Aspekt für Führungskräfte, die einen Blick auf den Cluster werfen möchten – sie wollen sehen, dass „alles grün ist“ und sich so beruhigen, dass „alles funktioniert“ (was natürlich ziemlich relativ ist... aber das führt bereits über den Rahmen des Artikels hinaus).

Als Standard-CI-System verwenden wir angewendet GitLab: Es wird von allen Entwicklern genutzt. Um ihnen den Zugriff zu ermöglichen, war es logisch, das Dashboard mit den GitLab-Konten zu integrieren.

Ich möchte auch erwähnen, dass wir NGINX Ingress verwenden. Wenn Sie jedoch mit anderen Ingress-Lösungen, müssen Sie selbst-altalternative Annotations finden für die Authentifizierung.

Versuchen wir die Integration

Installation des Dashboards

Achtung: Wenn Sie die im Folgenden beschriebenen Schritte wiederholen möchten, lesen Sie bitte zuerst bis zur nächsten Überschrift.

Da diese Integration in vielen unseren Installationen verwendet wird, haben wir ihre Installation automatisiert. Die benötigten Quellcodes sind in einem speziellen GitHub-Repository. Sie basieren auf geringfügig modifizierten YAML-Konfigurationen aus dem offiziellen Dashboard-Repository, sowie einem Bash-Skript zur schnellen Bereitstellung.

Das Skript installiert das Dashboard im Cluster und konfiguriert es zur Integration mit GitLab:

$ .\/ctl.sh  
Verwendung: ctl.sh [OPTION]... --gitlab-url GITLAB_URL --oauth2-id ID --oauth2-secret SECRET --dashboard-url DASHBOARD_URL
Installieren Sie das Kubernetes-Dashboard im Kubernetes-Cluster.
Verpflichtende Argumente:
 -i, --install                Installation im 'kube-system' Namespace
 -u, --upgrade                Upgrade einer vorhandenen Installation, Verwendung der Passwörter und Hostnamen
 -d, --delete                 Alles entfernen, einschließlich des Namespace
     --gitlab-url             Setzen Sie die GitLab-URL mit Schema (https://gitlab.example.com)
     --oauth2-id              Setzen Sie OAUTH2_PROXY_CLIENT_ID von GitLab
     --oauth2-secret          Setzen Sie OAUTH2_PROXY_CLIENT_SECRET von GitLab
     --dashboard-url          Setzen Sie die Dashboard-URL ohne Schema (dashboard.example.com)
Optionale Argumente:
 -h, --help                   Diese Meldung ausgeben

Bevor Sie es verwenden, müssen Sie jedoch in GitLab gehen: Adminbereich → Anwendungen — und eine neue Anwendung für das zukünftige Dashboard hinzufügen. Nennen wir es „Kubernetes-Dashboard“:

Nach dem Hinzufügen wird GitLab Hashes bereitstellen:

Diese werden als Argumente für das Skript verwendet. Folglich sieht die Installation folgendermaßen aus:

$ .\/ctl.sh -i --gitlab-url https://gitlab.example.com --oauth2-id 6a52769e… --oauth2-secret 6b79168f… --dashboard-url dashboard.example.com

Überprüfen wir danach, dass alles läuft:

$ kubectl -n kube-system get pod | egrep '(dash|oauth)'
kubernetes-dashboard-76b55bc9f8-xpncp   1\/1       Laufen   0          14s
oauth2-proxy-5586ccf95c-czp2v           1\/1       Laufen   0          14s

Früher oder später wird alles gestartet, jedoch Die Authentifizierung wird nicht sofort funktionieren! Der Grund ist, dass der verwendete Image (die Situation ist bei anderen Images ähnlich) den Prozess des Auffangens von Redirects im Callback nicht korrekt implementiert hat. Dadurch löscht OAuth das Cookie, das es selbst bereitstellt…

Das Problem kann durch den Bau eines eigenen OAuth-Images mit einem Patch behoben werden.

Patch für OAuth und die erneute Installation

Dazu verwenden wir die folgende Dockerfile:

FROM golang:1.9-alpine3.7
WORKDIR \/go\/src\/github.com\/bitly\/oauth2_proxy

RUN apk --update add make git build-base curl bash ca-certificates wget 
&& update-ca-certificates 
&& curl -sSO https://raw.githubusercontent.com/pote/gpm/v1.4.0/bin/gpm 
&& chmod +x gpm 
&& mv gpm \/usr\/local\/bin
RUN git clone https://github.com/bitly/oauth2_proxy.git . 
&& git checkout bfda078caa55958cc37dcba39e57fc37f6a3c842  
ADD rd.patch .
RUN patch -p1 < rd.patch 
&& .\/dist.sh

FROM alpine:3.7
RUN apk --update add curl bash ca-certificates && update-ca-certificates
COPY --from=0 \/go\/src\/github.com\/bitly\/oauth2_proxy\/dist\/ \/bin\/

EXPOSE 8080 4180
ENTRYPOINT [ "/bin/oauth2_proxy" ]
CMD [ "--upstream=http:\/\/0.0.0.0:8080\/

So sieht der Patch rd.patch aus

diff --git a/dist.sh b/dist.sh
index a00318b..92990d4 100755
--- a/dist.sh
+++ b/dist.sh
@@ -14,25 +14,13 @@ goversion=$(go version | awk '{print $3}')
sha256sum=()
 
echo "... führe Tests aus"
-. /test.sh
+#. /test.sh
 
-für os in windows linux darwin; do
-    echo "... erstelle v$version für $os/$arch"
-    EXT=
-    wenn [ $os = windows ]; dann
-        EXT=".exe"
-    fi
-    BUILD=$(mktemp -d ${TMPDIR:-/tmp}/oauth2_proxy.XXXXXX)
-    TARGET="oauth2_proxy-$version.$os-$arch.$goversion"
-    FILENAME="oauth2_proxy-$version.$os-$arch$EXT"
-    GOOS=$os GOARCH=$arch CGO_ENABLED=0 
-        go build -ldflags="-s -w" -o $BUILD/$TARGET/$FILENAME || exit 1
-    pushd $BUILD/$TARGET
-    sha256sum+=("$(shasum -a 256 $FILENAME || exit 1)")
-    cd .. && tar czvf $TARGET.tar.gz $TARGET
-    mv $TARGET.tar.gz $DIR/dist
-    popd
-done
+os='linux'
+echo "... erstelle v$version für $os/$arch"
+TARGET="oauth2_proxy-$version.$os-$arch.$goversion"
+GOOS=$os GOARCH=$arch CGO_ENABLED=0 
+    go build -ldflags="-s -w" -o ./dist/oauth2_proxy || exit 1
  
checksum_file="sha256sum.txt"
cd $DIR/dists
diff --git a/oauthproxy.go b/oauthproxy.go
index 21e5dfc..df9101a 100644
--- a/oauthproxy.go
+++ b/oauthproxy.go
@@ -381,7 +381,9 @@ func (p *OAuthProxy) SignInPage(rw http.ResponseWriter, req *http.Request, code
       wenn redirect_url == p.SignInPath {
               redirect_url = "/"
       }
-
+       wenn req.FormValue("rd") != "" {
+               redirect_url = req.FormValue("rd")
+       }
       t := struct {
               ProviderName  string
               SignInMessage string

Jetzt können wir das Image erstellen und es in unser GitLab pushen. Weiter geht's in manifests/kube-dashboard-oauth2-proxy.yaml wir geben die benötigte Image-Nutzung an (ersetzen Sie es durch Ihr eigenes):

 image: docker.io/colemickens/oauth2_proxy:latest

Wenn Sie ein durch Authentifizierung geschütztes Repository haben, vergessen Sie nicht, das Secret für den Image-Pull zu verwenden:

      imagePullSecrets:
     - name: gitlab-registry

… und fügen Sie das Secret für das Repository hinzu:

---
apiVersion: v1
data:
 .dockercfg: eyJyZWdpc3RyeS5jb21wYW55LmNvbSI6IHsKICJ1c2VybmFtZSI6ICJvYXV0aDIiLAogInBhc3N3b3JkIjogIlBBU1NXT1JEIiwKICJhdXRoIjogIkFVVEhfVE9LRU4iLAogImVtYWlsIjogIm1haWxAY29tcGFueS5jb20iCn0KfQoK
=
kind: Secret
metadata:
 annotations:
 name: gitlab-registry
 namespace: kube-system
type: kubernetes.io/dockercfg

Auffällige Leser werden feststellen, dass die obige lange Zeichenfolge die base64-Kodierung der Konfiguration ist:

{"registry.company.com": {
 "username": "oauth2",
 "password": "PASSWORD",
 "auth": "AUTH_TOKEN",
 "email": "mail@company.com"
}
}

Dies sind die Benutzerdaten in GitLab, mit denen Kubernetes das Image aus dem Repository pullen wird.

Nachdem alles erledigt ist, kann die aktuelle (falsch funktionierende) Dashboard-Installation mit dem Befehl gelöscht werden:

$ ./ctl.sh -d

… und alles neu installiert werden:

$ .\/ctl.sh -i --gitlab-url https://gitlab.example.com --oauth2-id 6a52769e… --oauth2-secret 6b79168f… --dashboard-url dashboard.example.com

Es ist Zeit, das Dashboard zu besuchen und die ziemlich veraltete Autorisierungs-Schaltfläche zu finden:

Nach dem Klicken werden wir von GitLab begrüßt, das uns anbietet, uns auf seiner vertrauten Seite anzumelden (natürlich, wenn wir uns dort nicht bereits vorher angemeldet haben):

Wir melden uns mit unseren GitLab-Anmeldedaten an – und alles ist geschehen:

Über die Möglichkeiten des Dashboards

Wenn Sie ein Entwickler sind, der noch nie mit Kubernetes gearbeitet hat, oder aus irgendeinem Grund noch nicht mit dem Dashboard in Berührung gekommen ist, möchte ich einige seiner Funktionen verdeutlichen.

Zunächst kann man sehen, dass "alles grün" ist:

Für Pods sind auch detailliertere Informationen verfügbar, wie Umgebungsvariablen, heruntergeladenes Bild, Startargumente und deren Zustand:

Bei Deployments sind die Status sichtbar:

… und weitere Details:

… und es gibt auch die Möglichkeit, das Deployment zu skalieren:

Das Ergebnis dieser Operation:

Zu den vielen nützlichen Funktionen, die bereits zu Beginn des Artikels erwähnt wurden, gehört das Ansehen von Logs:

… und die Funktion, in die Konsole der Container des ausgewählten Pods einzutreten:

Man kann beispielsweise auch die Limits/Requests auf den Knoten anzeigen:

Natürlich sind dies nicht alle Funktionen des Dashboards, aber ich hoffe, dass ein allgemeines Bild entstanden ist.

Nachteile der Integration und des Dashboards

In der beschriebenen Integration gibt es keine Zugriffskontrolle. Damit haben alle Benutzer, die irgendwelchen Zugang zu GitLab haben, auch Zugang zum Dashboard. Der Zugang im Dashboard ist für sie identisch und entspricht den Rechten des Dashboards, die im RBAC definiert werden. Offensichtlich eignet sich das nicht für jeden, aber in unserem Fall war es ausreichend.

Zu den auffälligen Nachteilen des Dashboards zähle ich die folgenden:

• man kann nicht in die Konsole des Init-Containers gelangen;
• man kann Deployments und StatefulSets nicht bearbeiten, obwohl dies im ClusterRole angepasst werden kann;
• die Kompatibilität des Dashboards mit den neuesten Kubernetes-Versionen und die Zukunft des Projekts werfen Fragen auf.

Das letzte Problem verdient besondere Aufmerksamkeit.

Status und Alternativen des Dashboards

Die Kompatibilitätstabelle des Dashboards mit den Releases von Kubernetes, die in der letzten Version des Projekts präsentiert wurde (v1.10.1), ist nicht besonders erfreulich:

Trotzdem gibt es (bereits im Januar angenommen) PR #3476, der die Unterstützung von K8s 1.13 ankündigt. Darüber hinaus finden sich unter den Issues des Projekts Erwähnungen von Benutzern, die mit dem Dashboard in K8s 1.14 arbeiten. Schließlich gehen die Commits in die Codebasis des Projekts weiter. Daher ist der aktuelle Status des Projekts (mindestens!) nicht so schlecht, wie es zunächst aus der offiziellen Kompatibilitätstabelle erscheinen mag.

Letztendlich gibt es Alternativen zum Dashboard. Darunter:

1. K8Dash — eine junge Benutzeroberfläche (die ersten Commits datieren auf März dieses Jahres), die bereits ansprechende Möglichkeiten bietet, wie die visuelle Darstellung des aktuellen Status des Clusters und die Verwaltung seiner Objekte. Sie wird als „Echtzeit-Interface“ positioniert, da sie die angezeigten Daten automatisch aktualisiert, ohne dass die Seite im Browser neu geladen werden muss.
2. OpenShift Console — ein Web-Interface von Red Hat OpenShift, das jedoch auch andere Ergebnisse des Projekts in Ihr Cluster bringt, was nicht für alle passend ist.
3. Kubernator — ein interessantes Projekt, das als niedrigstufiger (im Vergleich zum Dashboard) Interface mit der Möglichkeit zur Ansicht aller Clusterobjekte geschaffen wurde. Es sieht jedoch so aus, als ob die Entwicklung eingestellt wurde.
4. Polaris — buchstäblich vor wenigen Tagen angekündigt ein Projekt, das Funktionen eines Panels vereint (zeigt den aktuellen Zustand des Clusters an, verwaltet jedoch nicht dessen Objekte) und die automatische „Validierung von Best Practices“ (prüft den Cluster auf Korrektheit der Konfigurationen der darin ausgeführten Deployments).

Statt von Ausgaben

Dashboard — das Standardwerkzeug für die Kubernetes-Cluster, die wir verwalten. Seine Integration mit GitLab ist ebenfalls Teil unserer „Standardinstallation“ geworden, da viele Entwickler über die Möglichkeiten, die ihnen dieses Dashboard bietet, erfreut sind.

Für das Kubernetes Dashboard gibt es regelmäßig Alternativen aus der Open Source-Community (und wir freuen uns, diese in Betracht zu ziehen), doch in diesem Stadium bleiben wir bei dieser Lösung.

P.S.

Lesen Sie auch in unserem Blog:

• «kubebox und andere Konsolenoberflächen für Kubernetes»;
• «Best Practices für CI/CD mit Kubernetes und GitLab (Überblick und Video-Präsentation)»;
• «Build und Deployment von Anwendungen in Kubernetes mit dapp und GitLab CI»;
• «GitLab CI für kontinuierliche Integration und Bereitstellung in der Produktion. Teil 1: Unser Pipeline».

Quelle: habr.com