Kubernetes Dashboard und GitLab-Integration

Das Kubernetes Dashboard ist ein benutzerfreundliches Tool, mit dem Sie aktuelle Informationen zu einem funktionierenden Cluster erhalten und nur minimale Kontrolle darüber haben. Sie werden es noch mehr zu schätzen wissen, wenn nicht nur Administratoren / DevOps-Ingenieure auf diese Funktionen zugreifen müssen, sondern auch diejenigen, die weniger an die Konsole gewöhnt sind und / oder nicht beabsichtigen, sich mit allen Feinheiten der Interaktion mit kubectl und anderen Dienstprogrammen zu befassen. So geschah es bei uns: Die Entwickler wollten einen schnellen Zugriff auf die Kubernetes-Weboberfläche, und da wir GitLab verwenden, kam die Lösung natürlich.

Warum ist das so?

Direktentwickler sind möglicherweise an einem Tool wie K8s Dashboard zum Debuggen von Aufgaben interessiert. Manchmal möchten Sie Protokolle und Ressourcen anzeigen und manchmal Pods beenden, Deployments / StatefulSets skalieren und sogar in die Containerkonsole gehen (es gibt auch Anforderungen, für die es einen anderen Weg gibt, beispielsweise durch kubectl-debug ).

Darüber hinaus gibt es für Manager einen psychologischen Moment, in dem sie sich den Cluster ansehen möchten - um zu sehen, dass „alles grün ist“, und damit zu beruhigen, dass „alles funktioniert“ (was natürlich sehr relativ ist ... aber dies geht über den Rahmen des Artikels hinaus )

Wir verwenden GitLab als Standard-CI-System: Alle Entwickler verwenden es. Um ihnen Zugriff zu gewähren, war es daher logisch, Dashboard in Konten in GitLab zu integrieren.

Beachten Sie auch, dass wir NGINX Ingress verwenden. Wenn Sie mit anderen Ingress-Lösungen arbeiten , müssen Sie unabhängig Analoga von Anmerkungen für die Autorisierung finden.

Wir versuchen die Integration

Installieren Sie das Dashboard

Achtung : Wenn Sie die unten beschriebenen Schritte wiederholen möchten, lesen Sie - um unnötige Vorgänge zu vermeiden - zuerst den nächsten Untertitel durch.

Da wir diese Integration in vielen Installationen verwenden, haben wir die Installation automatisiert. Die dafür erforderlichen Quellen werden in einem speziellen GitHub-Repository veröffentlicht . Sie basieren auf leicht modifizierten YAML-Konfigurationen aus dem offiziellen Dashboard-Repository sowie einem Bash-Skript für eine schnelle Bereitstellung.

Das Skript installiert Dashboard in einem Cluster und konfiguriert es für die Integration in 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 können, 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 seiner Hinzufügung wird GitLab Hashes bereitstellen:



Sie werden als Argumente für das Skript verwendet. Infolgedessen ist die Installation wie folgt:

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

Überprüfen Sie danach, ob alles gestartet ist:

 $ 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 beginnen, aber die Autorisierung wird nicht sofort funktionieren ! Tatsache ist, dass in dem verwendeten Bild (die Situation in anderen Bildern ist ähnlich) der Umleitungsfangprozess im Rückruf falsch implementiert ist. Dieser Umstand führt dazu, dass oauth den Cookie löscht, der uns selbst (oauth) zur Verfügung stellt ...

Das Problem wird gelöst, indem Sie Ihr Oauth-Image mit dem Patch erstellen.

Patch zum Oauth und Neuinstallieren

Verwenden Sie dazu 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 \ && go get -u github.com/golang/dep/cmd/dep \ && 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 fa2771998a98a5bfdfa3c3503757668ac4f1c8ec 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" ] 

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

  image: docker.io/colemickens/oauth2_proxy:latest 

Wenn Sie eine durch Autorisierung geschlossene Registrierung haben, vergessen Sie nicht, ein Geheimnis zum Abrufen von Bildern hinzuzufügen:

  imagePullSecrets: - name: gitlab-registry 

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

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

Ein aufmerksamer Leser wird sehen, dass die obige lange Zeile base64 aus der Konfiguration ist:

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

Dies sind die Benutzerdaten in GitLab, dem Code, mit dem Kubernetes das Bild aus der Registrierung abruft.

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

 $ ./ctl.sh -d 

... und alles neu installieren:

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

Es ist Zeit, in das Dashboard zu gehen und die ziemlich archaische Anmeldeschaltfläche zu finden:



Nachdem Sie darauf geklickt haben, wird GitLab uns treffen und Ihnen anbieten, sich auf seiner vertrauten Seite anzumelden (natürlich, wenn wir dort nicht vorautorisiert waren):



Melden Sie sich mit Ihren GitLab-Anmeldeinformationen an - und alles ist passiert:

Informationen zu Dashboard-Funktionen

Wenn Sie ein Entwickler sind, der zuvor nicht mit Kubernetes gearbeitet hat oder aus irgendeinem Grund zuvor nicht auf Dashboard gestoßen ist, werde ich einige seiner Funktionen veranschaulichen.

Erstens können Sie sehen, dass "alles grün ist":



Für Pods sind detailliertere Daten verfügbar, z. B. Umgebungsvariablen, entleertes Image, Startargumente und deren Status:



Die Bereitstellungsstatus sind sichtbar:



... und andere Details:



... sowie die Möglichkeit, die Bereitstellung zu skalieren:



Das Ergebnis dieser Operation:



Zu den bereits am Anfang des Artikels erwähnten nützlichen Funktionen gehört das Anzeigen von Protokollen:



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



Beispielsweise können Sie auch das Limit / die Anforderung auf den Knoten anzeigen:



Natürlich sind dies nicht alle Merkmale des Panels, aber ich hoffe, dass sich die allgemeine Idee entwickelt hat.

Nachteile von Integration und Dashboard

In der beschriebenen Integration gibt es keine Zugriffskontrolle . Damit erhalten alle Benutzer, die Zugriff auf GitLab haben, Zugriff auf das Dashboard. Sie haben denselben Zugriff auf das Dashboard, entsprechend den Rechten des Dashboards selbst, die in RBAC definiert sind. Dies ist natürlich nicht für jeden geeignet, aber für unseren Fall hat es sich als ausreichend erwiesen.

Von den auffälligen Minuspunkten im Dashboard 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 Dashboard-Kompatibilität mit den neuesten Versionen von Kubernetes und die Zukunft des Projekts werfen Fragen auf.

Das letztere Problem verdient besondere Aufmerksamkeit.

Dashboard-Status und Alternativen

Die Dashboard-Kompatibilitätstabelle mit Kubernetes-Versionen, die in der neuesten Version des Projekts ( v1.10.1 ) vorgestellt wird, ist nicht sehr zufrieden:



Trotzdem gibt es (bereits im Januar verabschiedet) PR # 3476 , das die Unterstützung für K8s 1.13 ankündigt. Darüber hinaus finden Sie unter den Themen des Projekts Verweise auf Benutzer, die mit dem Panel in K8s 1.14 arbeiten. Schließlich werden Commits zur Projektcodebasis nicht beendet. Also (zumindest!) Der tatsächliche Status des Projekts ist nicht so schlecht, wie es zuerst aus der offiziellen Kompatibilitätstabelle hervorgeht.

Schließlich hat Dashboard Alternativen. Unter ihnen:

1. K8Dash ist eine junge Benutzeroberfläche (die ersten Commits sind auf März dieses Jahres datiert), die bereits gute Funktionen bietet, z. B. eine visuelle Darstellung des aktuellen Status des Clusters und die Verwaltung seiner Objekte. Positioniert als "Echtzeitschnittstelle", weil Aktualisiert die angezeigten Daten automatisch, ohne dass eine Seitenaktualisierung im Browser erforderlich ist.
2. OpenShift Console ist eine Webschnittstelle von Red Hat OpenShift, die jedoch andere Projektentwicklungen in Ihren Cluster bringt, die nicht für jeden geeignet sind.
3. Kubernator ist ein interessantes Projekt, das als untergeordnete Schnittstelle (als Dashboard) erstellt wurde und alle Objekte im Cluster anzeigen kann. Es sieht jedoch so aus, als ob die Entwicklung gestoppt ist.
4. Polaris hat erst neulich ein Projekt angekündigt , das die Funktionen eines Panels (zeigt den aktuellen Status des Clusters, verwaltet aber seine Objekte nicht) und die automatische "Best Practice Validation" (überprüft den Cluster auf die korrekte Konfiguration der darin ausgeführten Bereitstellungen) kombiniert.

Anstelle von Schlussfolgerungen

Dashboard ist das Standardwerkzeug für die von uns bereitgestellten Kubernetes-Cluster. Die Integration in GitLab ist auch Teil unserer „Standardinstallation“ geworden, da viele Entwickler mit den Möglichkeiten, die sie mit diesem Panel haben, zufrieden sind.

Kubernetes Dashboard bietet regelmäßig Alternativen aus der Open Source-Community (und wir prüfen diese gerne), aber wir bleiben in dieser Phase bei dieser Lösung.

PS

Lesen Sie auch in unserem Blog:

• " Kubebox und andere Konsolen-Shells für Kubernetes ";
• „ Beste CI / CD-Praktiken mit Kubernetes und GitLab (Rezension und Videobericht) “;
• " Erstellen und Installieren von Anwendungen in Kubernetes mit dapp und GitLab CI ";
• „ GitLab CI für die kontinuierliche Integration und Bereitstellung in der Produktion. Teil 1: Unsere Pipeline . “

UPD Laut dem Whoch-Bericht wurde im Patch ein Fehler gefunden (Tabulatoren wurden durch Leerzeichen ersetzt). Der Patch im Artikel wurde aktualisiert.