Integration von Kubernetes Dashboard- und GitLab-Benutzern

Kubernetes Dashboard ist ein benutzerfreundliches Tool, mit dem Sie aktuelle Informationen über Ihren laufenden Cluster abrufen und ihn mit minimalem Aufwand verwalten können. Sie beginnen es noch mehr zu schätzen, wenn der Zugriff auf diese Funktionen nicht nur von Administratoren/DevOps-Ingenieuren benötigt wird, sondern auch von denen, die weniger mit der Konsole vertraut sind und/oder sich nicht mit allen Feinheiten der Interaktion mit kubectl befassen möchten andere Dienstprogramme. Bei uns ist das passiert: Die Entwickler wollten einen schnellen Zugriff auf die Kubernetes-Weboberfläche, und da wir GitLab verwenden, war die Lösung eine Selbstverständlichkeit.

Warum ist das so?

Direkte Entwickler könnten an einem Tool wie K8s Dashboard für Debugging-Aufgaben interessiert sein. Manchmal möchten Sie Protokolle und Ressourcen anzeigen und manchmal Pods töten, Deployments/StatefulSets skalieren und sogar zur Containerkonsole gehen (es gibt auch solche Anfragen, für die es jedoch einen anderen Weg gibt – zum Beispiel durch kubectl-debug).

Darüber hinaus gibt es für Manager einen psychologischen Moment, wenn sie sich den Cluster ansehen möchten – um zu sehen, dass „alles grün ist“ und sich so zu vergewissern, dass „alles funktioniert“ (was natürlich sehr relativ ist ... aber das würde den Rahmen des Artikels sprengen).

Als Standard-CI-System haben wir gilt GitLab: Alle Entwickler nutzen es auch. Um ihnen Zugriff zu ermöglichen, war es daher logisch, Dashboard mit GitLab-Konten zu integrieren.

Ich möchte auch darauf hinweisen, dass wir NGINX Ingress verwenden. Wenn Sie mit anderen zusammenarbeiten Ingress-Lösungen, müssen Sie für die Autorisierung selbstständig Analoga von Anmerkungen finden.

Versuche Integration

Dashboard-Installation

Achtung: Wenn Sie die folgenden Schritte wiederholen möchten, lesen Sie zunächst zur nächsten Unterüberschrift, um unnötige Vorgänge zu vermeiden.

Da wir diese Integration in vielen Installationen nutzen, haben wir die Installation automatisiert. Die hierfür benötigten Quellen sind in veröffentlicht spezielles GitHub-Repository. Sie basieren auf leicht modifizierten YAML-Konfigurationen von offizielles Dashboard-Repositorysowie ein Bash-Skript für eine schnelle Bereitstellung.

Das Skript installiert Dashboard im Cluster und konfiguriert es für die Integration mit GitLab:

$ ./ctl.sh  
Usage: ctl.sh [OPTION]... --gitlab-url GITLAB_URL --oauth2-id ID --oauth2-secret SECRET --dashboard-url DASHBOARD_URL
Install kubernetes-dashboard to Kubernetes cluster.
Mandatory arguments:
 -i, --install                install into 'kube-system' namespace
 -u, --upgrade                upgrade existing installation, will reuse password and host names
 -d, --delete                 remove everything, including the namespace
     --gitlab-url             set gitlab url with schema (https://gitlab.example.com)
     --oauth2-id              set OAUTH2_PROXY_CLIENT_ID from gitlab
     --oauth2-secret          set OAUTH2_PROXY_CLIENT_SECRET from gitlab
     --dashboard-url          set dashboard url without schema (dashboard.example.com)
Optional arguments:
 -h, --help                   output this message

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

Als Ergebnis des Hinzufügens stellt GitLab die Hashes bereit:

Sie werden als Argumente für das Skript verwendet. Im Ergebnis sieht die Installation so aus:

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

Überprüfen wir anschließend, ob alles begonnen hat:

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

Früher oder später wird jedoch alles beginnen Die Autorisierung funktioniert nicht sofort! Tatsache ist, dass im verwendeten Bild (die Situation in anderen Bildern ist ähnlich) der Prozess des Abfangens einer Weiterleitung im Rückruf falsch implementiert ist. Dieser Umstand führt dazu, dass oauth das Cookie löscht, das uns oauth selbst zur Verfügung stellt...

Das Problem lässt sich lösen, indem man mit einem Patch ein eigenes OAuth-Image erstellt.

OAuth patchen und neu installieren

Dazu verwenden wir die folgende Docker-Datei:

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/", "--http-address=0.0.0.0:4180" ]

Und so sieht der rd.patch-Patch selbst 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 "... running tests"
-./test.sh
+#./test.sh
 
-for os in windows linux darwin; do
-    echo "... building v$version for $os/$arch"
-    EXT=
-    if [ $os = windows ]; then
-        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 "... building v$version for $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
       if redirect_url == p.SignInPath {
               redirect_url = "/"
       }
-
+       if req.FormValue("rd") != "" {
+               redirect_url = req.FormValue("rd")
+       }
       t := struct {
               ProviderName  string
               SignInMessage string

Jetzt können Sie das Image erstellen und in unser GitLab übertragen. Als nächstes drin manifests/kube-dashboard-oauth2-proxy.yaml Geben Sie die Verwendung des gewünschten Bildes an (ersetzen Sie es durch Ihr eigenes):

 image: docker.io/colemickens/oauth2_proxy:latest

Wenn Sie eine Registrierung haben, die durch Autorisierung geschlossen wird, vergessen Sie nicht, die Verwendung eines Geheimnisses für Pull-Images hinzuzufügen:

      imagePullSecrets:
     - name: gitlab-registry

... und fügen Sie das Geheimnis selbst für die Registrierung hinzu:

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

Der aufmerksame Leser wird erkennen, dass die lange Zeichenfolge oben base64 aus der Konfiguration ist:

{"registry.company.com": {
 "username": "oauth2",
 "password": "PASSWORD",
 "auth": "AUTH_TOKEN",
 "email": "[email protected]"
}
}

Dies sind die Benutzerdaten in GitLab. Der Kubernetes-Code ruft das Image aus der Registrierung ab.

Nachdem alles erledigt ist, können Sie die aktuelle (nicht korrekt funktionierende) Dashboard-Installation mit dem folgenden Befehl entfernen:

$ ./ctl.sh -d

... und alles noch einmal installieren:

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

Es ist Zeit, zum Dashboard zu gehen und eine ziemlich veraltete Anmeldeschaltfläche zu finden:

Nachdem wir darauf geklickt haben, begrüßt uns GitLab und bietet an, uns auf seiner gewohnten Seite anzumelden (natürlich, wenn wir uns dort noch nicht angemeldet haben):

Wir melden uns mit GitLab-Zugangsdaten an – und alles ist erledigt:

Über Dashboard-Funktionen

Wenn Sie ein Entwickler sind, der noch nie mit Kubernetes gearbeitet hat oder einfach aus irgendeinem Grund noch nie mit Dashboard in Berührung gekommen ist, werde ich einige seiner Funktionen veranschaulichen.

Erstens sieht man, dass „alles grün ist“:

Für Pods sind auch detailliertere Daten verfügbar, z. B. Umgebungsvariablen, heruntergeladene Bilder, Startargumente und deren Status:

Bereitstellungen haben sichtbare Status:

...und weitere Details:

... und es besteht auch die Möglichkeit, den Einsatz zu skalieren:

Das Ergebnis dieser Operation:

Zu den weiteren nützlichen Funktionen, die bereits am Anfang des Artikels erwähnt wurden, gehört die Anzeige von Protokollen:

... und die Funktion zum Anmelden an der Containerkonsole des ausgewählten Pods:

Sie können sich beispielsweise auch die Limits/Anforderungen an Knoten ansehen:

Natürlich sind dies nicht alle Funktionen des Panels, aber ich hoffe, dass Sie einen allgemeinen Überblick bekommen.

Nachteile der Integration und des Dashboards

In der beschriebenen Integration gibt es keine Zugangskontrolle. Damit erhalten alle Benutzer mit Zugriff auf GitLab Zugriff auf das Dashboard. Sie haben den gleichen Zugriff im Dashboard selbst, entsprechend den Rechten des Dashboards selbst werden in RBAC definiert. Natürlich ist dies nicht für jeden geeignet, aber für unseren Fall hat es sich als ausreichend erwiesen.

Unter den auffälligen Nachteilen des Dashboards selbst stelle ich Folgendes fest:

• es ist unmöglich, in die Konsole des Init-Containers zu gelangen;
• Es ist nicht möglich, Bereitstellungen und StatefulSets zu bearbeiten, obwohl dies in ClusterRole behoben werden kann.
• Die Kompatibilität von Dashboard mit den neuesten Versionen von Kubernetes und die Zukunft des Projekts werfen Fragen auf.

Das letzte Problem verdient besondere Aufmerksamkeit.

Dashboard-Status und Alternativen

Dashboard-Kompatibilitätstabelle mit Kubernetes-Versionen, dargestellt in der neuesten Version des Projekts (v1.10.1), nicht sehr glücklich:

Dennoch gibt es (bereits im Januar verabschiedet) PR # 3476, das die Unterstützung für K8s 1.13 ankündigt. Darüber hinaus finden Sie in den Projektausgaben Hinweise auf Benutzer, die mit dem Panel in K8s 1.14 arbeiten. Endlich, begeht in die Codebasis des Projekts hören nicht auf. Der tatsächliche Status des Projekts ist also (zumindest!) nicht so schlecht, wie es anhand der offiziellen Kompatibilitätstabelle zunächst erscheinen mag.

Schließlich gibt es Alternativen zum Dashboard. Unter ihnen:

1. K8Dash — eine junge Schnittstelle (die ersten Commits stammen aus dem März dieses Jahres), die bereits gute Features bietet, wie zum Beispiel eine visuelle Darstellung des aktuellen Status des Clusters und die Verwaltung seiner Objekte. Als „Echtzeitschnittstelle“ positioniert, weil Die angezeigten Daten werden automatisch aktualisiert, ohne dass Sie die Seite im Browser aktualisieren müssen.
2. OpenShift-Konsole - ein Webinterface von Red Hat OpenShift, das allerdings andere Entwicklungen des Projekts in Ihren Cluster bringt, was nicht für jeden geeignet ist.
3. Kubernator ist ein interessantes Projekt, das als Schnittstelle auf niedrigerer Ebene (als Dashboard) mit der Möglichkeit erstellt wurde, alle Clusterobjekte anzuzeigen. Es sieht jedoch so aus, als ob seine Entwicklung gestoppt wurde.
4. Polaris - erst vor Kurzem angekündigt ein Projekt, das die Funktionen eines Panels (zeigt den aktuellen Status des Clusters an, verwaltet jedoch nicht seine Objekte) und der automatischen „Validierung von Best Practices“ (überprüft den Cluster auf die Richtigkeit der Konfigurationen der darin ausgeführten Bereitstellungen).

Anstelle von Schlussfolgerungen

Dashboard ist ein Standardtool für die von uns betreuten Kubernetes-Cluster. Die Integration mit GitLab ist ebenfalls Teil unserer Standardinstallation geworden, da viele Entwickler von den Möglichkeiten dieses Panels begeistert sind.

Kubernetes Dashboard bietet regelmäßig Alternativen aus der Open-Source-Community (und wir ziehen sie gerne in Betracht), aber zum jetzigen Zeitpunkt bleiben wir bei dieser Lösung.

PS

Lesen Sie auch auf unserem Blog:

• «kubebox und andere Shells für Kubernetes";
• «Beste CI/CD-Praktiken mit Kubernetes und GitLab (Rezension und Videobericht)";
• «Erstellen und implementieren Sie Anwendungen in Kubernetes mit Dapp und GitLab CI";
• «GitLab CI für kontinuierliche Integration und Bereitstellung in der Produktion. Teil 1: unsere Pipeline".

Source: habr.com