Integration af Kubernetes Dashboard og GitLab-brugere

Kubernetes Dashboard — et brugervenligt værktøj til at få aktuelle oplysninger om det kørende cluster og begrænset administration af det. Man begynder at værdsætte det endnu mere, når adgangen til disse funktioner ikke kun er nødvendig for administratorer/DevOps-ingeniører, men også for dem, der ikke er så vant til konsollen og/eller ikke ønsker at sætte sig ind i alle nuancerne ved at interagere med kubectl og andre værktøjer. Det var også vores situation: udviklerne ønskede hurtig adgang til webgrænsefladen for Kubernetes, og da vi bruger GitLab, var løsningen nærliggende.

Hvorfor det?

Direkte udviklere kan være interesserede i et værktøj som K8s Dashboard til debugging-opgaver. Nogle gange vil man gerne se logs og ressourcer, og af og til også dræbe pods, skalere Deployments/StatefulSets og endda tilgå containerens konsol (der dukker sig sådanne forespørgsler op, som dog kan løses på andre måder — for eksempel gennem kubectl-debug).

Derudover er der et psykologisk aspekt for ledere, når de ønsker at se på clustret — se at 'alt er grønt', og på den måde berolige sig med, at 'alt fungerer' (hvilket selvfølgelig er meget relativt... men det ligger uden for rammerne af denne artikel).

Som standard CI-system bruger vi typeforbindelse GitLab: det benyttes også af alle udviklere. Derfor var det logisk at integrere Dashboard med konti i GitLab for at give dem adgang.

Jeg vil også nævne, at vi bruger NGINX Ingress. Hvis du arbejder med andre ingress-løsninger, skal du selv finde alternativer til annotationerne til godkendelse.

Vi prøver integrationen

Installation af Dashboard

Bemærk: Hvis du planlægger at gentage de nedenstående trin, så — for at undgå unødvendige operationer — skal du først læse til det næste underoverskrift.

Da denne integration bruges af os i mange installationer, har vi automatiseret installationen. Kildematerialet, der kræves til dette, er offentliggjort i et særligt GitHub-repositorium. De er baseret på let modificerede YAML-konfigurationer fra det officielle repository for Dashboard, samt et Bash-script til hurtig udrulning.

Scriptet installerer Dashboard i clustret 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å ind i GitLab: Admin område → Applikationer — og tilføje en ny applikation til den fremtidige panel. Lad os kalde den "kubernetes dashboard":

Som resultat af tilføjelsen vil GitLab give hashes:

Det er dem, der bruges som argumenter til scriptet. Som 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

Derefter skal vi kontrollere, at alt er startet:

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

Før eller siden vil alt starte, men autorisationen vil ikke fungere med det samme! Problemet er, at den anvendte billede (situationen i andre billeder er analog) har en forkert implementering af processen til at fange redirect i callback. Dette skyldes, at oauth sletter den cookie, som det selv (oauth) giver os...

Problemet kan løses ved at bygge dit eget oauth-billede med en patch.

Patch til oauth og geninstallation

Til dette vil vi bruge 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 sådan ser selve patchen rd.patch 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 "... kører tests"
-.\/test.sh
+#.\/test.sh
 
-for os in windows linux darwin; do
-    echo "... bygger v$version til $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 "... bygger v$version til $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 vi bygge billedet og 'push' det op til vores GitLab. Herefter i manifests/kube-dashboard-oauth2-proxy.yaml angiver vi brugen af det nødvendige billede (erstat det med dit eget):

 image: docker.io/colemickens/oauth2_proxy:latest

Hvis du har en privat autoriseringsregistry — glem ikke at tilføje brugen af en hemmelighed til at trække billeder:

      imagePullSecrets:
     - name: gitlab-registry

… og tilføj selve hemmeligheden til registry:

---
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 bemærke, at den lange streng ovenfor — er en base64-kodet version af konfigurationen:

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

Dette er brugeroplysningerne i GitLab, som Kubernetes vil bruge til at trække billedet fra registry.

Når alt er gjort, kan du slette den nuværende (fejlbehæftede) installation af Dashboard med kommandoen:

$ .\/ctl.sh -d

… og geninstallere alt:

$ ./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 logge ind på Dashboard og finde den ret gammeldags autoriseringsknap:

Når vi trykker på den, vil vi møde GitLab, der tilbyder os at logge ind på deres velkendte side (selvfølgelig hvis vi ikke allerede er logget ind der):

Vi logger ind med vores GitLab-legitimationsoplysninger — og så er det gjort:

Om Dashboardets muligheder

Hvis du er en udvikler, der ikke tidligere har arbejdet med Kubernetes, eller hvis du 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 man se, at "alt er grønt":

For pods er der også mere detaljerede data, såsom miljøvariabler, hentet billede, opstartargomentoer, deres tilstand:

Statusserne for deployments er synlige:

… og andre detaljer:

… og der er også mulighed for at skalere deployment:

Resultatet af denne operation:

Blandt andre nyttige funktioner, der allerede er nævnt i starten af artiklen, er visning af logs:

… og funktionen til at logge ind i konsollen for containerne i den valgte pod:

Man kan også se limitters/requeste på noder:

Selvfølgelig er dette ikke alle mulighederne i panelet, men jeg håber, at der er dannet et samlet indtryk.

Ulemper ved integration og Dashboard

I den beskrevne integration er der ikke nogen adgangsbegrænsning. Med den har alle brugere, der har en eller anden adgang til GitLab, adgang til Dashboard. Adgangen i selve Dashboard er ens for dem, svarende til rettighederne for selve Dashboard, som defineres i RBAC. Det er tydeligt, at dette ikke vil passe til alle, men for vores tilfælde viste det sig at være tilstrækkeligt.

Blandt de bemærkelsesværdige ulemper ved selve Dashboard-panelet nævner jeg følgende:

• det er umuligt at få adgang til konsollen for init-containere;
• det er umuligt at redigere Deployments og StatefulSets, selvom det kan rettes i ClusterRole;
• kompatibiliteten af Dashboard med de nyeste versioner af Kubernetes og projektets fremtid vækker spørgsmål.

Det sidste problem fortjener særlig opmærksomhed.

Status og alternativer til Dashboard

Kompatibilitetstabellen for Dashboard med Kubernetes-udgivelser præsenteret i den seneste version af projektet (v1.10.1), glæder ikke så meget:

På trods af dette er der (allerede accepteret i januar) PR #3476, som annoncerer støtte til K8s 1.13. Derudover kan man blandt problemstillingerne i projektet finde omtaler af brugere, der arbejder med panelet i K8s 1.14. Endelig committene til projektets kodebase stopper ikke. Så (i det mindste!) er den faktiske status for projektet ikke så dårlig, som den først kan se ud fra den officielle kompatibilitetstabel.

Endelig har Dashboard alternativer. Blandt dem:

1. K8Dash — det unge interface (de første commits går tilbage til marts i år), tilbyder allerede en god række muligheder, såsom visuel fremvisning af den aktuelle status for klyngen og administration af dens objekter. Det positioneres som et "real-time interface", da det automatisk opdaterer de viste data uden at kræve en sideopdatering i browseren.
2. OpenShift Console — webinterfacet fra Red Hat OpenShift, som dog også vil bringe andre projekter ind i din klynge, hvilket ikke passer alle.
3. Kubernator — et interessant projekt, skabt som et mere lavt niveau (end Dashboard) interface med mulighed for at se alle objekter i klyngen. Det virker dog som om, udviklingen er blevet stoppet.
4. Polaris — bogstaveligt talt for nylig annonceret projekt, der kombinerer funktioner fra et panel (viser den aktuelle tilstand af klyngen, men administrerer ikke dens objekter) og automatisk "validering af bedste praksis" (tjekker klyngen for korrekthed af konfigurationerne for de udrulninger, der kører i den).

I stedet for konklusioner

Dashboard — det standardværktøj til Kubernetes-klynger, som vi vedligeholder. Dets integration med GitLab er også blevet en del af vores "standardinstallation", da mange udviklere er glade for de muligheder, de får med dette panel.

Der er periodisk alternativer til Kubernetes Dashboard fra Open Source-fællesskabet (og vi er glade for at overveje dem), men på nuværende tidspunkt holder vi os til denne løsning.

P.S.

Læs også på vores blog:

• «kubebox og andre kommandolinjegrænseflader til Kubernetes»;
• «Bedste praksis for CI/CD med Kubernetes og GitLab (oversigt og videopræsentation)»;
• «Bygning og deployment af applikationer i Kubernetes ved hjælp af dapp og GitLab CI»;
• «GitLab CI til kontinuerlig integration og levering i produktion. Del 1: vores pipeline».

Kilde: habr.com