Integrering av Kubernetes Dashboard og GitLab-brukere

Kubernetes Dashboard er et brukervennlig verktøy for å få oppdatert informasjon om den aktive klyngen og for minimal administrasjon av den. Du setter pris på det enda mer når tilgangen til disse funksjonene ikke bare er nødvendig for administratorer/DevOps-ingeniører, men også for dem som er mindre vant til konsollen eller som ikke ønsker å sette seg inn i alle nyansene ved samhandling med kubectl og andre verktøy. Slik skjedde det også hos oss: utviklerne ønsket rask tilgang til webgrensesnittet for Kubernetes, og siden vi bruker GitLab, var løsningen åpenbar.

Hvorfor det?

Direkte utviklere kan være interessert i et verktøy som K8s Dashboard for feilsøkingsoppgaver. Av og til ønsker man å se på logger og ressurser, og noen ganger til og med drepe pod-er, skalere Deployments/StatefulSets og til og med gå inn i konsollen for containere (det skjer også forespørseler for slike oppgaver, som imidlertid kan løses på en annen måte — for eksempel via kubectl-debug).

I tillegg er det et psykologisk aspekt for ledere når de ønsker å se på klyngen — se at «alt er grønt», og slik føler seg beroliget om at «alt fungerer» (som selvfølgelig er ganske relativt... men det overskrider allerede rammer for denne artikkelen).

Som standard CI-system bruker vi kompilatoren GitLab: Dette brukes av alle utviklerne. Derfor var det logisk å gjøre en integrering av Dashboard med GitLab-kontoene for å gi dem tilgang.

Jeg vil også påpeke at vi bruker NGINX Ingress. Dersom du jobber med andre ingress-løsninger, må du selv finne alternativer til annotasjonene for autorisasjon.

Vi prøver integreringen

Installering av Dashboard

Obs: Hvis du planlegger å gjenta stegene beskrevet nedenfor, anbefales det å lese ferdig til neste underoverskrift først for å unngå unødvendige operasjoner.

Siden denne integreringen brukes av oss i mange installasjoner, har vi automatisert installeringen. Kildene som kreves for dette er offentliggjort i et spesial GitHub-repositorium. De er basert på svakt modifiserte YAML-konfigurasjoner fra det offisielle Dashboard-repositoriet, samt et Bash-skript for rask distribusjon.

Skriptet installerer Dashboard i klyngen og konfigurerer det for integrasjon med GitLab:

$ .\/ctl.sh  
Bruk: ctl.sh [VALG]... --gitlab-url GITLAB_URL --oauth2-id ID --oauth2-secret SECRET --dashboard-url DASHBOARD_URL
Installer kubernetes-dashboard til Kubernetes-klyngen.
Obligatoriske argumenter:
 -i, --install                installer i 'kube-system' namespace
 -u, --upgrade                oppgradere eksisterende installasjon, vil gjenbruke passord og vertsnavn
 -d, --delete                 fjerne alt, inkludert namespace
     --gitlab-url             sett gitlab-url med skjema (https:\/\/gitlab.example.com)
     --oauth2-id              sett OAUTH2_PROXY_CLIENT_ID fra gitlab
     --oauth2-secret          sett OAUTH2_PROXY_CLIENT_SECRET fra gitlab
     --dashboard-url          sett dashboard-url uten skjema (dashboard.example.com)
Valgfritt argument:
 -h, --help                   viser denne meldingen

Men før du bruker det, må du gå til GitLab: Admin-område → Applikasjoner — og legge til en ny applikasjon for den fremtidige panelet. La oss kalle det «kubernetes dashboard»:

Som et resultat av tillegget vil GitLab gi hashene:

Disse brukes som argumenter til skriptet. Som et resultat, ser installasjonen slik ut:

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

Deretter vil vi sjekke at alt har startet:

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

Tid eller annet vil alt starte, men umiddelbart vil autentiseringen ikke fungere! Det er slik at i det brukte bildet (situasjonen i andre bilder er lik) er prosessen for å fange omdirigeringen i callback implementert feil. Denne omstendigheten fører til at oauth sletter informasjonskapselen, som oauth selv gir oss...

Problemet løses ved å bygge ditt eget oauth-bilde med patch.

Patch til oauth og ny installasjon

For dette bruker 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\/\n
EXPOSE 8080 4180
ENTRYPOINT [ "\/bin\/oauth2_proxy" ]
CMD [ "--upstream=http:\/\/0.0.0.0:8080\/", "--http-address=0.0.0.0:4180" ]

Slik ser selve patchen rd.patch ut

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 "... kjører tester"
-.\/test.sh
+#.\/test.sh
 
-for os in windows linux darwin; do
-    echo "... bygger 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 "... bygger 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

Nå kan vi bygge bildet og 'pushe' det til vår egen GitLab. Deretter i manifests/kube-dashboard-oauth2-proxy.yaml vi spesifiserer bruken av det nødvendige bildet (erstatte det med ditt):

 image: docker.io/colemickens/oauth2_proxy:latest

Hvis du har et registreringsvindu med autentisering — husk å legge til en hemmelighet for å dra bildene:

      imagePullSecrets:
     - name: gitlab-registry

… og legg til selve hemmeligheten for registreringen:

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

Den oppmerksomme leseren vil se at den lange strengen ovenfor — er base64 av konfigurasjonen:

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

Dette er brukerdataene i GitLab, koden som Kubernetes vil bruke for å dra bildet fra registreringen.

Når alt er gjort, kan vi fjerne den nåværende (feilaktige) installasjonen av Dashboard med kommandoen:

$ .\/ctl.sh -d

… og installere alt på nytt:

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

Det er på tide å gå til Dashboard og finne den ganske gammeldagse autorisasjonsknappen:

Etter å ha klikket på den, vil vi bli møtt av GitLab som tilbyr å logge inn på sin vante side (selvfølgelig, hvis vi ikke allerede har logget inn der):

Vi autoriserer med GitLab-legitimasjonen — og alt er gjort:

Om mulighetene til Dashboard

Hvis du er utvikler som aldri har arbeidet med Kubernetes før, eller av en eller annen grunn ikke har støtt på Dashboard tidligere, vil jeg illustrere noen av dets muligheter.

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

For pod-er er det også tilgjengelige mer detaljerte data, som miljøvariabler, hentet bilde, oppstartargumenter, deres tilstand:

For deployment-er kan vi se statusene:

… og andre detaljer:

… og det er også mulighet for å skalere deployment:

Resultatet av denne operasjonen:

Blant de andre nyttige funksjonene, allerede nevnt i begynnelsen av artikkelen, er visning av logger:

… og funksjonen for å få tilgang til konsollen til containerne i den valgte pod-en:

I tillegg kan vi for eksempel se limit-er/request-er på nodene:

Selvfølgelig er dette ikke alle funksjonene til panelet, men jeg håper at du får et godt overblikk.

Ulemper med integrasjonen og Dashboard

I den beskrevne integrasjonen finnes det ingen tilgangsbegrensning. Med den får alle brukere som har noe tilgang til GitLab, tilgang til Dashboard. Tilgang i selve Dashboard er lik for dem, som tilsvarer rettighetene i selve Dashboard, som defineres i RBAC. Åpenbart passer ikke dette for alle, men for vårt tilfelle viste det seg å være tilstrekkelig.

Av bemerkelsesverdige ulemper med selve Dashboard-panelet nevner jeg følgende:

• det er ikke mulig å få tilgang til konsollen til init-containeren;
• det er ikke mulig å redigere Deployments og StatefulSets, selv om dette kan rettes i ClusterRole;
• kompatibiliteten til Dashboard med de nyeste versjonene av Kubernetes og fremtiden til prosjektet reiser spørsmål.

Den siste betegnelsen fortjener spesiell oppmerksomhet.

Status og alternativer til Dashboard

Tabellen for kompatibilitet mellom Dashboard og Kubernetes-utgivelser, presentert i den siste versjonen av prosjektet (v1.10.1), er ikke veldig oppløftende:

Til tross for dette finnes det (allerede akseptert i januar) PR #3476, som annonserer støtte for K8s 1.13. I tillegg kan vi finne omtaler fra brukere som jobber med panelet i K8s 1.14 blant problemene i prosjektet. Til slutt, commits til kodebasen til prosjektet opphører ikke. Så (minst!) er den faktiske statusen til prosjektet ikke så dårlig som man først kan anta fra den offisielle kompatibilitetstabellen.

Til slutt har Dashboard alternativer. Blant dem:

1. K8Dash — et ungt grensesnitt (de første committene er datert til mars i år) som allerede tilbyr anstendige muligheter, som visuell representasjon av nåværende status for klyngen og styring av dens objekter. Posisjoneres som "sanntidsgrensesnitt", da det automatisk oppdaterer viste data uten å kreve at man oppdaterer siden i nettleseren.
2. OpenShift Console — et webgrensesnitt fra Red Hat OpenShift, som imidlertid vil bringe med seg andre resultater fra prosjektet til klyngen din, noe som ikke passer for alle.
3. Kubernator — et interessant prosjekt, utviklet som et lavere nivå (enn Dashboard) grensesnitt med mulighet for å se alle objektene i klyngen. Likevel ser det ut til at utviklingen har stoppet.
4. Polaris — kun nylig annonsert et prosjekt som kombinerer funksjoner fra panelet (viser nåværende tilstand av klyngen, men styrer ikke objektene) og automatisk "validering av beste praksis" (sjekker klyngen for korrekthet i konfigurasjoner av Deployments som kjører i den).

I stedet for konklusjoner

Dashboard — det standardverktøyet for Kubernetes-klynger vi betjener. Integrasjonen med GitLab er også blitt en del av vår "standardinstallasjon", siden mange utviklere er glade for de mulighetene de får med dette panelet.

Det dukker jevnlig opp alternativer til Kubernetes Dashboard fra Open Source-samfunnet (og vi vurderer dem gjerne), men på nåværende tidspunkt holder vi oss til denne løsningen.

P.S.

Also read in our blog:

• «kubebox og andre konsollskall for Kubernetes»;
• «Beste praksis for CI/CD med Kubernetes og GitLab (oversikt og videoforedrag)»;
• «Bygging og deployering av applikasjoner i Kubernetes med dapp og GitLab CI»;
• «GitLab CI for kontinuerlig integrering og levering til produksjon. Del 1: vår pipeline».

Kilde: habr.com