Integration af Kubernetes Dashboard og GitLab-brugere

Kubernetes Dashboard er et letanvendeligt værktøj til at få opdateret information om din kørende klynge og administrere den med minimal indsats. Du begynder at sætte endnu mere pris på det, når adgang til disse funktioner ikke kun er påkrævet af administratorer/DevOps-ingeniører, men også af dem, der er mindre vant til konsollen og/eller ikke har til hensigt at håndtere alle forviklingerne ved at interagere med kubectl og andre forsyningsselskaber. Dette skete hos os: Udviklerne ønskede hurtig adgang til Kubernetes webgrænseflade, og da vi bruger GitLab, kom løsningen naturligt.

Hvorfor er det?

Direkte udviklere kan være interesseret i et værktøj som K8s Dashboard til fejlfindingsopgaver. Nogle gange vil du se logfiler og ressourcer og nogle gange dræbe pods, skalere Deployments/StatefulSets og endda gå til containerkonsollen (der er også anmodninger, som der dog er en anden måde til - f.eks. kubectl-debug).

Derudover er der et psykologisk øjeblik for ledere, når de vil se på klyngen - at se, at "alt er grønt", og dermed forsikre sig om, at "alt fungerer" (hvilket selvfølgelig er meget relativt... men dette er uden for artiklens omfang).

Som et standard CI-system har vi anvendt GitLab: alle udviklere bruger det også. Derfor, for at give dem adgang, var det logisk at integrere Dashboard med GitLab-konti.

Jeg vil også bemærke, at vi bruger NGINX Ingress. Hvis du arbejder sammen med andre indgangsløsninger, skal du selvstændigt finde analoger til annoteringer til godkendelse.

Prøver integration

Installation af instrumentbræt

Attention: Hvis du vil gentage nedenstående trin, så - for at undgå unødvendige handlinger - læs først til næste underoverskrift.

Da vi bruger denne integration i mange installationer, har vi automatiseret installationen. De nødvendige kilder hertil er offentliggjort i særligt GitHub-lager. De er baseret på let modificerede YAML-konfigurationer fra officielt Dashboard-lager, samt et Bash-script til hurtig implementering.

Scriptet installerer Dashboard i klyngen og konfigurerer det til integration med 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

Men før du bruger det, skal du gå til GitLab: Admin område → Programmer - og tilføje en ny applikation til det fremtidige panel. Lad os kalde det "kubernetes dashboard":

Som et resultat af at tilføje det, vil GitLab levere hasherne:

Det er dem, der bruges som argumenter til scriptet. Som et resultat ser installationen således ud:

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

Lad os derefter kontrollere, at alt startede:

$ 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

Men før eller siden starter alting autorisation virker ikke umiddelbart! Faktum er, at i det anvendte billede (situationen i andre billeder er lignende) er processen med at fange en omdirigering i tilbagekaldet implementeret forkert. Denne omstændighed fører til, at oauth sletter den cookie, som oauth selv giver os...

Problemet er løst ved at bygge dit eget oauth-billede med en patch.

Patch oauth og geninstaller

For at gøre dette bruger vi følgende 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" ]

Og her er, hvordan selve rd.patch-patchen ser ud

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

Nu kan du bygge billedet og skubbe det ind i vores GitLab. Næste ind manifests/kube-dashboard-oauth2-proxy.yaml angiv brugen af ​​det ønskede billede (erstat det med dit eget):

 image: docker.io/colemickens/oauth2_proxy:latest

Hvis du har et register, der er lukket med autorisation, så glem ikke at tilføje brugen af ​​en hemmelighed til pull-billeder:

      imagePullSecrets:
     - name: gitlab-registry

... og tilføje selve hemmeligheden til registreringsdatabasen:

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

Den opmærksomme læser vil se, at den lange streng ovenfor er base64 fra konfigurationen:

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

Dette er brugerdataene i GitLab, Kubernetes-koden vil trække billedet fra registreringsdatabasen.

Når alt er gjort, kan du fjerne den aktuelle (fungerer ikke korrekt) Dashboard-installation med kommandoen:

$ ./ctl.sh -d

... og installer alt igen:

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

Det er tid til at gå til Dashboard og finde en ret arkaisk login-knap:

Efter at have klikket på den, vil GitLab hilse på os og tilbyde at logge ind på sin sædvanlige side (selvfølgelig, hvis vi ikke tidligere har logget ind der):

Vi logger ind med GitLab-legitimationsoplysninger - og alt er gjort:

Om Dashboard-funktioner

Hvis du er en udvikler, der ikke har arbejdet med Kubernetes før, eller blot af en eller anden grund ikke har stødt på Dashboard før, vil jeg illustrere nogle af dets muligheder.

For det første kan du se, at "alt er grønt":

Mere detaljerede data er også tilgængelige for pods, såsom miljøvariabler, downloadet billede, startargumenter og deres tilstand:

Implementeringer har synlige statusser:

...og andre detaljer:

... og der er også mulighed for at skalere implementeringen:

Resultatet af denne operation:

Blandt andre nyttige funktioner, der allerede er nævnt i begyndelsen af ​​artiklen, er at se logfiler:

... og funktionen til at logge ind på containerkonsollen på den valgte pod:

For eksempel kan du også se på grænserne/anmodningerne på noder:

Det er selvfølgelig ikke alle panelets muligheder, men jeg håber, at du forstår den generelle idé.

Ulemper ved integration og Dashboard

I den beskrevne integration er der ingen adgangskontrol. Med den får alle brugere med enhver adgang til GitLab adgang til Dashboardet. De har samme adgang i selve Dashboardet, svarende til rettighederne til selve Dashboardet, som er defineret i RBAC. Det er naturligvis ikke egnet for alle, men for vores tilfælde viste det sig at være tilstrækkeligt.

Blandt de mærkbare ulemper i selve Dashboardet bemærker jeg følgende:

• det er umuligt at komme ind i konsollen på initbeholderen;
• det er umuligt at redigere Deployments og StatefulSets, selvom dette kan rettes i ClusterRole;
• Dashboards kompatibilitet med de seneste versioner af Kubernetes og fremtiden for projektet rejser spørgsmål.

Det sidste problem fortjener særlig opmærksomhed.

Dashboard status og alternativer

Dashboard-kompatibilitetstabel med Kubernetes-udgivelser, præsenteret i den seneste version af projektet (v1.10.1), ikke særlig glad:

På trods af dette er der (allerede vedtaget i januar) PR #3476, som annoncerer understøttelse af K8s 1.13. Derudover kan du blandt projektnumrene finde referencer til brugere, der arbejder med panelet i K8s 1.14. Endelig, forpligter sig ind i projektets kodebase stopper ikke. Så (i det mindste!) den faktiske status for projektet er ikke så slem, som det først kunne se ud fra den officielle kompatibilitetstabel.

Endelig er der alternativer til Dashboard. Blandt dem:

1. K8Dash — en ung grænseflade (den første commits går tilbage til marts i år), som allerede tilbyder gode funktioner, såsom en visuel repræsentation af klyngens nuværende status og styring af dens objekter. Placeret som en "real-time interface", fordi opdaterer automatisk de viste data uden at du behøver at opdatere siden i browseren.
2. OpenShift-konsol - en webgrænseflade fra Red Hat OpenShift, som dog vil bringe andre udviklinger af projektet til din klynge, som ikke er egnet for alle.
3. Kubernator er et interessant projekt, skabt som en grænseflade på lavere niveau (end Dashboard) med mulighed for at se alle klyngeobjekter. Det ser dog ud til, at udviklingen er stoppet.
4. Polaris - lige den anden dag annonceret et projekt, der kombinerer funktionerne i et panel (viser klyngens aktuelle tilstand, men administrerer ikke dets objekter) og automatisk "validering af bedste praksis" (kontrollerer klyngen for rigtigheden af ​​konfigurationerne af implementeringer, der kører i den).

I stedet for konklusioner

Dashboard er et standardværktøj til de Kubernetes-klynger, vi betjener. Dets integration med GitLab er også blevet en del af vores standardinstallation, da mange udviklere er begejstrede for de muligheder, de har med dette panel.

Kubernetes Dashboard har med jævne mellemrum alternativer fra Open Source-fællesskabet (og vi overvejer dem gerne), men på nuværende tidspunkt forbliver vi med denne løsning.

PS

Læs også på vores blog:

• «kubebox og andre skaller til Kubernetes";
• «Bedste CI/CD-praksis med Kubernetes og GitLab (gennemgang og videorapport)";
• «Byg og implementer applikationer i Kubernetes ved hjælp af dapp og GitLab CI";
• «GitLab CI til kontinuerlig integration og levering i produktionen. Del 1: vores pipeline'.

Kilde: www.habr.com