🥇Integration av Kubernetes Dashboard och GitLab-användare

Kubernetes Dashboard är ett användarvänligt verktyg för att få aktuell information om en fungerande kluster och för att hantera det minimalt. Du börjar uppskatta det ännu mer när åtkomst till dessa funktioner behövs inte bara av administratörer/DevOps-ingenjörer, utan även av dem som är mindre vana vid konsolen och/eller inte har för avsikt att fördjupa sig i alla subtiliteter kring interaktionen med kubectl och andra verktyg. Så har det blivit för oss: utvecklarna ville ha snabb åtkomst till webgränssnittet för Kubernetes, och eftersom vi använder GitLab blev lösningen uppenbar.

Varför detta?

Direkta utvecklare kan vara intresserade av ett verktyg som K8s Dashboard för felsökningsuppgifter. Ibland vill man granska loggar och resurser, och ibland till och med döda pods, skala Deployments/StatefulSets och till och med komma åt containrarnas konsol (det förekommer sådana förfrågningar, för att lösa vilka det dock finns en annan väg — till exempel genom kubectl-debug).

Dessutom finns det en psykologisk aspekt för ledare, när de vill titta på klustret — se att "allt är grönt", och därmed lugna sig att "allt fungerar" (vilket naturligtvis är ganska relativt... men detta går redan utanför artikelns ämne).

Som standard CI-system använder vi använder GitLab: den används av alla utvecklare. Så för att ge dem tillgång var det logiskt att integrera Dashboard med konton i GitLab.

Jag noterar också att vi använder NGINX Ingress. Om du arbetar med andra ingress-lösningar, behöver du själv hitta motsvarande annoteringar för autentisering.

Vi testar integrationen

Installation av Dashboard

Observera: Om du planerar att upprepa de steg som beskrivs nedan, läs först fram till nästa underrubrik för att undvika onödiga åtgärder.

Eftersom denna integration används av oss i många installationer har vi automatiserat dess installation. Källkoden som behövs för detta har publicerats i ett speciellt GitHub-repository. De bygger på något modifierade YAML-konfigurationer från det officiella Dashboard-repositoryt, samt ett Bash-skript för snabb utrullning.

Skriptet installerar Dashboard i klustret och konfigurerar det för integration med GitLab:

$ ./ctl.sh  
Användning: ctl.sh [ALTERNATIV]... --gitlab-url GITLAB_URL --oauth2-id ID --oauth2-secret SECRET --dashboard-url DASHBOARD_URL
Installera kubernetes-dashboard i Kubernetes-klustret.
Obligatoriska argument:
 -i, --install                installera i 'kube-system' namespace
 -u, --upgrade                uppgradera befintlig installation, kommer att återanvända lösenord och värdnamn
 -d, --delete                 ta bort allt, inklusive namnet
     --gitlab-url             ställ in gitlab-url med schema (https://gitlab.example.com)
     --oauth2-id              ställ in OAUTH2_PROXY_CLIENT_ID från gitlab
     --oauth2-secret          ställ in OAUTH2_PROXY_CLIENT_SECRET från gitlab
     --dashboard-url          ställ in dashboard-url utan schema (dashboard.example.com)
Valfria argument:
 -h, --help                   visa detta meddelande

Men innan du använder det måste du gå till GitLab: Adminområde → Applikationer — och lägga till en ny applikation för den framtida panelen. Vi kallar den "kubernetes dashboard":

Som ett resultat av att den lagts till kommer GitLab att tillhandahålla hashvärden:

Dessa används som argument till skriptet. Så installationen ser ut som följer:

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

Efter detta kontrollerar vi att allt har startat:

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

Förr eller senare kommer allt att starta, men direkt kommer autentiseringen inte att fungera! Grejen är att i den använda bilden (situation i andra bilder är liknande) är processen för att fånga omdirigeringen i callback felaktigt implementerad. Detta leder till att oauth raderar cookies, som den själv (oauth) tillhandahåller oss...

Problemet löses genom att bygga en egen oauth-bild med en patch.

Patch för oauth och en ny installation

För detta ändamål använder vi följande 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" ]

Så här ser själva 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 "... kör tests"
-.\/test.sh
+#.\/test.sh
 
-for os in windows linux darwin; do
-    echo "... bygger v$version för $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 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 = "/"
       }
-
+       if req.FormValue("rd") != "" {
+               redirect_url = req.FormValue("rd")
+       }
       t := struct {
               ProviderName  string
               SignInMessage string

Nu kan vi bygga bilden och 'push' den till vår GitLab. Därefter i manifests/kube-dashboard-oauth2-proxy.yaml ange användningen av önskad bild (byt ut den mot din):

 image: docker.io/colemickens/oauth2_proxy:latest

Om du har en privat registrering med autentisering - glöm inte att lägga till sekretess för att dra bilder:

      imagePullSecrets:
     - name: gitlab-registry

… och lägg till själva hemligheten för registreringen:

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

Den uppmärksamma läsaren kommer att se att den ovanstående långa strängen är base64 av konfigurationen:

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

Detta är användardata för GitLab, koden som Kubernetes kommer att använda för att hämta bilden från registreringen.

När allt är klart kan vi ta bort den nuvarande (felaktigt fungerande) installationen av Dashboard med kommandot:

$ ./ctl.sh -d

… och installera allt på nytt:

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

Det är dags att gå till Dashboard och hitta den ganska föråldrade autentiseringsknappen:

När vi trycker på den möts vi av GitLab, som erbjuder oss att logga in på sin vanliga sida (naturligtvis om vi inte har loggat in där tidigare):

Vi autentiserar oss med våra GitLab-uppgifter — och allt är klart:

Om Dashboardens möjligheter

Om du är en utvecklare som inte tidigare har arbetat med Kubernetes, eller av någon anledning inte har stött på Dashboard tidigare, så ska jag illustrera några av dess funktioner.

För det första kan du se att "allt är grönt":

För poddar finns detaljerad information tillgänglig, såsom miljövariabler, nedladdad bild, startargument och deras status:

För deployment visas statusar:

… och andra detaljer:

… och det finns även möjlighet att skala upp deployment:

Resultatet av denna åtgärd:

Bland andra användbara funktioner som redan nämnts i början av artikeln, är att se loggar:

… och möjligheten att gå in i konsolen för containrar i den valda podden:

Dessutom kan man till exempel se limit/requests på noder:

Självklart är detta inte alla funktioner i panelen, men jag hoppas att en allmän bild har skapats.

Nackdelar med integration och Dashboard

I den beskrivna integrationen finns det inget åtkomstkontroll. Med det får alla användare som har någon åtkomst till GitLab också åtkomst till Dashboard. Åtkomsten i Dashboard är densamma för dem, vilken motsvarar rättigheterna i själva Dashboard, som bestäms av RBAC. Det är uppenbart att detta inte passar alla, men för vårt fall visade det sig vara tillräckligt.

Bland de märkvärdiga nackdelarna med själva Dashboard-panelen noterar jag följande:

det går inte att komma åt konsolen för init-containern;
det går inte att redigera Deployments och StatefulSets, även om detta kan åtgärdas i ClusterRole;
kompatibiliteten mellan Dashboard och de senaste versionerna av Kubernetes och projektets framtid väcker frågor.

Det sista problemet förtjänar särskild uppmärksamhet.

Status och alternativ till Dashboard

Kompatibilitetstabellen för Dashboard med Kubernetes versioner, som presenteras i den senaste versionen av projektet (v1.10.1), är inte särskilt upplyftande:

Trots detta finns det (redan accepterad i januari) PR #3476, som meddelar stöd för K8s 1.13. Dessutom kan man bland projektets problem hitta omnämnanden av användare som arbetar med panelen i K8s 1.14. Slutligen, commits i projektets kodbas upphör inte. Så (åtminstone!) är den faktiska statusen för projektet inte så dålig som den först kan verka utifrån den officiella kompatibilitetstabellen.

Till sist finns det alternativ till Dashboard. Bland dessa:

K8Dash — ett ungt gränssnitt (första commits dateras från mars i år) som redan erbjuder ganska bra möjligheter, såsom visuell representation av den aktuella statusen för klustret och hantering av dess objekt. Positioneras som "ett realtidsgränssnitt", eftersom det automatiskt uppdaterar de visade uppgifterna utan att behöva uppdatera sidan i webbläsaren.
OpenShift Console — ett webbgränssnitt från Red Hat OpenShift, som dock kommer att föra in andra resultat från projektet i ditt kluster, vilket kanske inte passar alla.
Kubernator — ett intressant projekt, skapat som ett mer låg nivå (än Dashboard) gränssnitt där man kan se alla objekt i klustret. Men det verkar som om dess utveckling har avstannat.
Polaris — bokstavligt talat nyligen annonserad ett projekt som kombinerar funktioner av en panel (visar den aktuella statusen för klustret men hanterar dess objekt) och automatisk "validering av bästa praxis" (kontrollerar klustret för korrekthet i konfigurationerna av de Deployments som körs i det).

Istället för slutsatser

Dashboard — standardverktyget för Kubernetes-kluster som vi underhåller. Dess integration med GitLab blev också en del av vår "standardinstallation", eftersom många utvecklare är glada över de möjligheter som öppnas med denna panel.

Det dyker regelbundet upp alternativ för Kubernetes Dashboard från Open Source-communityt (och vi är glada att överväga dem), men i dagsläget stannar vi med denna lösning.