Integration av Kubernetes Dashboard och GitLab-användare

Kubernetes Dashboard är ett lättanvänt verktyg för att få uppdaterad information om ditt löpande kluster och hantera det med minimal ansträngning. Du börjar uppskatta det ännu mer när åtkomst till dessa funktioner behövs inte bara av administratörer/DevOps-ingenjörer, utan också av de som är mindre vana vid konsolen och/eller inte har för avsikt att ta itu med alla krångligheterna med att interagera med kubectl och andra verktyg. Detta hände med oss: utvecklarna ville ha snabb tillgång till Kubernetes webbgränssnitt, och eftersom vi använder GitLab kom lösningen naturligt.

Varför är detta?

Direktutvecklare kan vara intresserade av ett verktyg som K8s Dashboard för felsökningsuppgifter. Ibland vill du se loggar och resurser, och ibland döda poddar, skala Deployments/StatefulSets och till och med gå till containerkonsolen (det finns också sådana förfrågningar, men det finns ett annat sätt för - t.ex. kubectl-debug).

Dessutom finns det ett psykologiskt ögonblick för chefer när de vill titta på klustret - att se att "allt är grönt", och därmed försäkra sig om att "allt fungerar" (vilket naturligtvis är väldigt relativt... men detta ligger utanför artikelns räckvidd).

Som ett standard CI-system har vi applicerad GitLab: alla utvecklare använder det också. Därför, för att ge dem åtkomst, var det logiskt att integrera Dashboard med GitLab-konton.

Jag kommer också att notera att vi använder NGINX Ingress. Om du jobbar med andra inträngande lösningar, måste du självständigt hitta analoger till annoteringar för auktorisering.

Försöker integration

Installation av instrumentbräda

Varning: Om du ska upprepa stegen nedan, läs först till nästa underrubrik - för att undvika onödiga operationer.

Eftersom vi använder denna integration i många installationer har vi automatiserat installationen. De källor som behövs för detta publiceras i speciellt GitHub-förråd. De är baserade på något modifierade YAML-konfigurationer från officiellt Dashboard-arkiv, samt ett Bash-skript för snabb distribution.

Skriptet installerar Dashboard i klustret och konfigurerar det för 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

Innan du använder den måste du dock gå till GitLab: Admin area → Applications - och lägga till en ny applikation för den framtida panelen. Låt oss kalla det "kubernetes instrumentpanel":

Som ett resultat av att lägga till det kommer GitLab att tillhandahålla hasharna:

Det är de som används som argument till manuset. Som ett resultat ser installationen ut så här:

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

Efter det, låt oss kontrollera att allt började:

$ 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

Förr eller senare börjar dock allt auktorisering kommer inte att fungera omedelbart! Faktum är att i bilden som används (situationen i andra bilder är liknande) är processen att fånga en omdirigering i återuppringningen implementerad felaktigt. Denna omständighet leder till att oauth raderar cookien som oauth själv tillhandahåller oss...

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

Patcha oauth och installera om

För att göra detta kommer vi att använda 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" ]

Och så här ser själva rd.patch-patchen 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 "... 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 bygga bilden och skjuta in den i vårt GitLab. Nästa in manifests/kube-dashboard-oauth2-proxy.yaml ange användningen av den önskade bilden (ersätt den med din egen):

 image: docker.io/colemickens/oauth2_proxy:latest

Om du har ett register som är stängt med auktorisering, glöm inte att lägga till användningen av en hemlighet för pull-bilder:

      imagePullSecrets:
     - name: gitlab-registry

... och lägg till själva hemligheten för registret:

---
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 långa strängen ovan är base64 från konfigurationen:

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

Detta är användardata i GitLab, Kubernetes-koden kommer att dra bilden från registret.

När allt är klart kan du ta bort den nuvarande (inte fungerar korrekt) Dashboard-installationen med kommandot:

$ ./ctl.sh -d

... och installera allt igen:

$ ./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 instrumentpanelen och hitta en ganska arkaisk inloggningsknapp:

Efter att ha klickat på den kommer GitLab att hälsa oss välkomna och erbjuda sig att logga in på sin vanliga sida (naturligtvis om vi inte tidigare har loggat in där):

Vi loggar in med GitLab-uppgifter - och allt är klart:

Om Dashboard-funktioner

Om du är en utvecklare som inte har arbetat med Kubernetes tidigare, eller helt enkelt av någon anledning inte har stött på Dashboard tidigare, kommer jag att illustrera några av dess möjligheter.

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

Mer detaljerad data är också tillgänglig för poddar, såsom miljövariabler, nedladdad bild, startargument och deras tillstånd:

Implementeringar har synliga statusar:

...och andra detaljer:

... och det finns också möjligheten att skala distributionen:

Resultatet av denna operation:

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

... och funktionen för att logga in på behållarkonsolen för den valda podden:

Till exempel kan du också titta på gränserna/förfrågningarna på noder:

Naturligtvis är detta inte alla funktioner i panelen, men jag hoppas att du förstår den allmänna uppfattningen.

Nackdelar med integration och Dashboard

I den beskrivna integrationen finns ingen åtkomstkontroll. Med den får alla användare med någon tillgång till GitLab tillgång till Dashboard. De har samma åtkomst i själva Dashboarden, motsvarande rättigheterna för själva Dashboarden, vilket definieras i RBAC. Uppenbarligen är detta inte lämpligt för alla, men för vårt fall visade det sig vara tillräckligt.

Bland de märkbara nackdelarna i själva instrumentpanelen noterar jag följande:

• det är omöjligt att komma in i konsolen på initbehållaren;
• det är omöjligt att redigera Deployments och StatefulSets, även om detta kan fixas i ClusterRole;
• Dashboards kompatibilitet med de senaste versionerna av Kubernetes och projektets framtid väcker frågor.

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

Instrumentpanelens status och alternativ

Dashboard-kompatibilitetstabell med Kubernetes-versioner, presenterad i den senaste versionen av projektet (v1.10.1), inte särskilt nöjd:

Trots detta finns det (redan antaget i januari) PR #3476, som tillkännager stöd för K8s 1.13. Dessutom kan du bland projektfrågorna hitta referenser till användare som arbetar med panelen i K8s 1.14. Till sist, begår in i projektets kodbas inte sluta. Så (åtminstone!) den faktiska statusen för projektet är inte så dålig som det först kan verka från den officiella kompatibilitetstabellen.

Slutligen finns det alternativ till Dashboard. Bland dem:

1. K8Dash — ett ungt gränssnitt (de första åtagandena går tillbaka till mars i år), som redan erbjuder bra funktioner, såsom en visuell representation av klustrets nuvarande status och hantering av dess objekt. Positionerad som ett "realtidsgränssnitt", eftersom uppdaterar automatiskt den visade informationen utan att du behöver uppdatera sidan i webbläsaren.
2. OpenShift-konsolen - ett webbgränssnitt från Red Hat OpenShift, som dock kommer att föra andra utvecklingar av projektet till ditt kluster, vilket inte är lämpligt för alla.
3. Kubernator är ett intressant projekt, skapat som ett gränssnitt på lägre nivå (än Dashboard) med möjlighet att se alla klusterobjekt. Det ser dock ut som att dess utveckling har avstannat.
4. Polaris - häromdagen meddelat ett projekt som kombinerar funktionerna i en panel (visar det aktuella tillståndet för klustret, men hanterar inte dess objekt) och automatisk "validering av bästa praxis" (kontrollerar klustret för korrektheten av konfigurationerna av distributioner som körs i det).

I stället för slutsatser

Dashboard är ett standardverktyg för de Kubernetes-kluster vi betjänar. Dess integration med GitLab har också blivit en del av vår standardinstallation, eftersom många utvecklare är entusiastiska över de möjligheter de har med den här panelen.

Kubernetes Dashboard har periodvis alternativ från Open Source-communityn (och vi överväger dem gärna), men i det här skedet står vi kvar med denna lösning.

PS

Läs även på vår blogg:

• «kubebox och andra skal för Kubernetes";
• «Bästa CI/CD-praxis med Kubernetes och GitLab (recension och videorapport)";
• «Bygg och distribuera applikationer i Kubernetes med hjälp av dapp och GitLab CI";
• «GitLab CI för kontinuerlig integration och leverans i produktion. Del 1: vår pipeline".

Källa: will.com