Integration des Kubernetes Dashboards und von GitLab-Benutzern

Kubernetes-Dashboard — ein benutzerfreundliches Tool, um aktuelle Informationen über den laufenden Cluster zu erhalten und ihn minimal zu verwalten. Man schätzt es erst richtig, wenn der Zugang zu diesen Funktionen nicht nur für Administratoren oder DevOps-Engineers, sondern auch für weniger erfahrene Nutzer von Bedeutung ist, die weniger mit der Konsole vertraut sind oder nicht in alle Feinheiten von kubectl und anderen Tools einsteigen möchten. So erging es uns: Die Entwickler wünschten sich schnellen Zugang zur Kubernetes-Weboberfläche, und da wir GitLab nutzen, bot sich eine Lösung regelrecht an.

Warum das?

Direktentwickler könnten an einem Tool wie dem K8s-Dashboard für Debugging-Aufgaben interessiert sein. Manchmal möchte man Protokolle und Ressourcen einsehen, gelegentlich auch Pods beenden, Deployments/StatefulSets skalieren und sogar auf die Konsolen von Containern zugreifen (solche Anforderungen treten auf, für deren Lösung es jedoch auch andere Wege gibt — beispielsweise über kubectl-debug).

Zudem gibt es einen psychologischen Aspekt für Führungskräfte, wenn sie einen Cluster betrachten möchten – sie wollen sehen, dass «alles grün» ist, und sich damit beruhigen, dass «alles funktioniert» (was natürlich relativ ist... aber das geht über den Rahmen dieses Artikels hinaus).

Als Standard-CI-System verwenden wir verwendet GitLab: Dies nutzen auch alle Entwickler. Daher war es nur logisch, eine Integration des Dashboards mit den GitLab-Konten bereitzustellen.

Ich möchte auch erwähnen, dass wir NGINX Ingress verwenden. Wenn Sie hingegen mit anderen Ingress-Lösungenarbeiten, müssen Sie eigenständig Nachfolger für die Autorisierungsannotation finden.

Wir testen die Integration

Installieren des Dashboards

Achtung: Wenn Sie die nachstehenden Schritte wiederholen möchten, lesen Sie bitte zuerst bis zur nächsten Überschrift weiter, um unnötige Aktionen zu vermeiden.

Da wir diese Integration in vielen Installationen verwenden, haben wir die Installation automatisiert. Die benötigten Ressourcen sind in einem speziellen GitHub-Repositoryveröffentlicht. Diese basieren auf geringfügig modifizierten YAML-Konfigurationen aus dem offiziellen Repository des Dashboards., sowie ein Bash-Skript für die schnelle Bereitstellung.

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

$ ./ctl.sh  
Benutzung: ctl.sh [OPTION]... --gitlab-url GITLAB_URL --oauth2-id ID --oauth2-secret SECRET --dashboard-url DASHBOARD_URL
Installiert das Kubernetes-Dashboard im Kubernetes-Cluster.
Erforderliche Argumente:
 -i, --install                in den Namespace 'kube-system' installieren
 -u, --upgrade                bestehende Installation aktualisieren, Passwort und Hostnamen wiederverwenden
 -d, --delete                 alles entfernen, einschließlich des Namespace
     --gitlab-url             GitLab-URL mit Schema festlegen (https://gitlab.example.com)
     --oauth2-id              OAUTH2_PROXY_CLIENT_ID von GitLab setzen
     --oauth2-secret          OAUTH2_PROXY_CLIENT_SECRET von GitLab setzen
     --dashboard-url          Dashboard-URL ohne Schema festlegen (dashboard.example.com)
Optionale Argumente:
 -h, --help                   diese Nachricht ausgeben

Bevor Sie es verwenden können, müssen Sie sich jedoch in GitLab anmelden: Admin-Bereich → Anwendungen — und eine neue Anwendung für das zukünftige Dashboard hinzufügen. Nennen wir es „kubernetes dashboard“:

Nach dessen Hinzufügung stellt GitLab die Hashes zur Verfügung:

Diese werden als Argumente für das Skript verwendet. Die Installation erfolgt dann wie folgt:

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

Danach überprüfen wir, ob alles gestartet wurde:

$ 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 alles gestartet, jedoch wird die Authentifizierung nicht sofort funktionieren! Das Problem ist, dass in dem verwendeten Image (die Situation in anderen Images ist ähnlich) der Prozess zum Abfangen der Weiterleitung im Callback nicht korrekt implementiert ist. Dies führt dazu, dass oauth das Cookie löscht, welches es selbst bereitstellt...

Das Problem kann gelöst werden, indem man sein eigenes oauth-Image mit einem Patch erstellt.

Patch für oauth und erneute Installation

Hierfür verwenden wir den folgenden 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/", "--http-address=0.0.0.0:4180" ]

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 "... Tests werden ausgeführt"
-./test.sh
+#./test.sh
 
-für os in windows linux darwin; do
-    echo "... Baue v$version für $os/$arch"
-    EXT=
-    wenn [ $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 "... Baue 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
       if 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 bauen und in unser GitLab pushen. Danach in manifests/kube-dashboard-oauth2-proxy.yaml werden wir die Verwendung des benötigten Images angeben (ersetzen Sie es durch Ihr eigenes):

 image: docker.io/colemickens/oauth2_proxy:latest

Wenn Sie ein authentifiziertes Registry haben, vergessen Sie nicht, das Secret für das Pullen der Images zu konfigurieren:

      imagePullSecrets:
     - name: gitlab-registry

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

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

Aufmerksame Leser werden feststellen, dass die obige lange Zeichenfolge ein base64-encoded Config 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 Registry pullt.

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

$ ./ctl.sh -d

… und alles von vorne 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 öffnen und die etwas veraltete Authentifizierungsschaltfläche zu finden:

Nach dem Klicken darauf werden wir mit GitLab konfrontiert, das uns anbietet, uns auf seiner gewohnten Seite anzumelden (natürlich, wenn wir uns nicht bereits dort angemeldet haben):

Wir melden uns mit unseren GitLab-Zugangsdaten an – und schon ist es 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 sind – ich werde einige seiner Funktionen veranschaulichen.

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

Für die Pods sind auch detailliertere Daten verfügbar, wie Umgebungsvariablen, das heruntergeladene Image, Startargumente und deren Status:

Bei den Deployments sind die Status sichtbar:

… und weitere Details:

… außerdem gibt es die Möglichkeit, das Deployment zu skalieren:

Das Ergebnis dieser Operation:

Unter anderem nützliche Funktionen, die bereits zu Beginn des Artikels erwähnt wurden – das Anzeigen von Logs:

… und die Funktion, sich mit der Konsole des gewählten Pods einzuloggen:

Außerdem kann man beispielsweise auch die Limits/Requests auf den Knoten einsehen:

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

Nachteile der Integration und des Dashboards

In der beschriebenen Integration gibt es keine Zugriffssteuerung. Damit erhalten alle Benutzer, die Zugang zu GitLab haben, auch Zugang zum Dashboard. Der Zugang im Dashboard selbst ist für sie identisch und entspricht den Rechten des Dashboards, die in RBAC festgelegt werden.Es ist offensichtlich, dass dies nicht für jeden geeignet ist, aber für unseren Fall war es ausreichend.

Zu den bemerkenswerten Nachteilen des Dashboards gehören folgende Punkte:

• kein Zugriff auf die Konsole des Init-Containers;
• Deployments und StatefulSets können nicht bearbeitet werden, obwohl dies im ClusterRole behoben 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 Beachtung.

Status und Alternativen des Dashboards

Die Kompatibilitätstabelle des Dashboards mit Kubernetes-Versionen, die in der neuesten Version des Projekts präsentiert wird (v1.10.1), ist nicht besonders erfreulich:

Trotzdem gibt es (bereits im Januar angenommenen) PR #3476, das die Unterstützung für K8s 1.13 ankündigt. Darüber hinaus kann man unter den Issues des Projekts Erwähnungen von Benutzern finden, die das Dashboard in K8s 1.14 verwenden. Schließlich halten die Commits an der Codebasis des Projekts nicht an. Somit ist der tatsächliche Status des Projekts (mindestens!) nicht so schlecht, wie es zunächst aus der offiziellen Kompatibilitätstabelle erscheinen mag.

Schließlich gibt es Alternativen zum Dashboard. Dazu gehören:

1. K8Dash — eine junge Benutzeroberfläche (die ersten Commits stammen aus dem März dieses Jahres), die bereits ansprechende Funktionen bietet, wie die visuelle Darstellung des aktuellen Status des Clusters und die Verwaltung seiner Objekte. Sie wird als "Echtzeit-Oberfläche" positioniert, da sie die angezeigten Daten automatisch aktualisiert, ohne dass die Seite im Browser neu geladen werden muss.
2. OpenShift Console — die webbasierte Oberfläche von Red Hat OpenShift, die jedoch auch andere Entwicklungen des Projekts in Ihr Cluster bringt, was nicht für jeden geeignet ist.
3. Kubernator — ein interessantes Projekt, das als eine niedrigere (als das Dashboard) Benutzeroberfläche entwickelt wurde, um alle Objekte des Clusters anzeigen zu können. Allerdings sieht es so aus, als wäre die Entwicklung eingestellt worden.
4. Polaris — buchstäblich vor wenigen Tagen angekündigtes Projekt, das Funktionen eines Dashboards vereint (zeigt den aktuellen Status des Clusters an, verwaltet jedoch seine Objekte nicht) und eine automatische "Validierung von Best Practices" (überprüft den Cluster auf Korrektheit der Konfigurationen der darin laufenden Deployments).

Statt Fazits

Dashboard — ein Standardwerkzeug für die Kubernetes-Cluster, die wir betreuen. Seine Integration mit GitLab gehört ebenfalls zu unserer Standardinstallation, da viele Entwickler die Möglichkeiten, die dieses Panel bietet, sehr zu schätzen wissen.

Für das Kubernetes Dashboard gibt es regelmäßig Alternativen aus der Open-Source-Community (und wir freuen uns, diese zu prüfen). Momentan bleiben wir jedoch 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 (Übersicht und Videovortrag)»;
• «Bau und Deployment von Anwendungen in Kubernetes mithilfe von dapp und GitLab CI»;
• «GitLab CI für kontinuierliche Integration und Bereitstellung in der Produktion. Teil 1: Unser Pipeline».

Quelle: habr.com