Kubernetes Dashboard er et brukervennlig verktøy for å få oppdatert informasjon om løpeklyngen din og administrere den med minimal innsats. Du begynner å sette enda mer pris på det når tilgang til disse egenskapene ikke bare er nødvendig for administratorer/DevOps-ingeniører, men også av de som er mindre vant til konsollen og/eller ikke har til hensikt å håndtere alle vanskelighetene med å samhandle med kubectl og andre verktøy. Dette skjedde med oss: Utviklerne ønsket rask tilgang til Kubernetes webgrensesnitt, og siden vi bruker GitLab kom løsningen naturlig.
Hvorfor er det sånn?
Direkte utviklere kan være interessert i et verktøy som K8s Dashboard for feilsøkingsoppgaver. Noen ganger vil du se logger og ressurser, og noen ganger drepe pods, skalere Deployments/StatefulSets, og til og med gå til containerkonsollen (det er også forespørsler som det imidlertid er en annen måte for - for eksempel gjennom ).
I tillegg er det et psykologisk øyeblikk for ledere når de vil se på klyngen - å se at "alt er grønt", og dermed forsikre seg om at "alt fungerer" (noe som selvfølgelig er veldig relativt ... men dette er utenfor rammen av artikkelen).
Som standard CI-system har vi GitLab: alle utviklere bruker det også. Derfor, for å gi dem tilgang, var det logisk å integrere Dashboard med GitLab-kontoer.
Jeg vil også merke at vi bruker NGINX Ingress. Hvis du jobber med andre , må du uavhengig finne analoger av merknader for autorisasjon.
Prøver integrering
Installasjon av dashbord
Oppmerksomhet: Hvis du skal gjenta trinnene nedenfor, så - for å unngå unødvendige operasjoner - les først til neste underoverskrift.
Siden vi bruker denne integrasjonen i mange installasjoner, har vi automatisert installasjonen. Kildene som trengs for dette er publisert i . De er basert på litt modifiserte YAML-konfigurasjoner fra , samt et Bash-skript for rask distribusjon.
Skriptet installerer Dashboard i klyngen og konfigurerer det for integrasjon 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 messageFør du bruker det, må du imidlertid gå til GitLab: Admin-område → Programmer - og legge til en ny applikasjon for det fremtidige panelet. La oss kalle det "kubernetes dashboard":
Som et resultat av å legge det til, vil GitLab gi hashen:
Det er de som brukes som argumenter til manuset. 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.comEtter det, la oss sjekke at alt startet:
$ 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 14sMen før eller siden starter alt autorisasjonen vil ikke fungere umiddelbart! Faktum er at i bildet som brukes (situasjonen i andre bilder er lik) er prosessen med å fange en omdirigering i tilbakeringingen 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 en patch.
Patch oauth og installer på nytt
For å gjøre 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/
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-oppdateringen ser 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
Nå kan du bygge bildet og skyve det inn i GitLab. Neste inn manifests/kube-dashboard-oauth2-proxy.yaml angi bruken av ønsket bilde (erstatt det med ditt eget):
image: docker.io/colemickens/oauth2_proxy:latestHvis du har et register som er lukket etter autorisasjon, ikke glem å legge til bruken av en hemmelighet for pull-bilder:
imagePullSecrets:
- name: gitlab-registry... og legg til selve hemmeligheten for registeret:
---
apiVersion: v1
data:
.dockercfg: eyJyZWdpc3RyeS5jb21wYW55LmNvbSI6IHsKICJ1c2VybmFtZSI6ICJvYXV0aDIiLAogInBhc3N3b3JkIjogIlBBU1NXT1JEIiwKICJhdXRoIjogIkFVVEhfVE9LRU4iLAogImVtYWlsIjogIm1haWxAY29tcGFueS5jb20iCn0KfQoK
=
kind: Secret
metadata:
annotations:
name: gitlab-registry
namespace: kube-system
type: kubernetes.io/dockercfgDen oppmerksomme leseren vil se at den lange strengen over er base64 fra konfigurasjonen:
{"registry.company.com": {
"username": "oauth2",
"password": "PASSWORD",
"auth": "AUTH_TOKEN",
"email": "[email protected]"
}
}Dette er brukerdataene i GitLab, Kubernetes-koden vil trekke bildet fra registeret.
Etter at alt er gjort, kan du fjerne gjeldende (fungerer ikke riktig) Dashboard-installasjonen med kommandoen:
$ ./ctl.sh -d... og installer alt på nytt:
$ ./ctl.sh -i --gitlab-url https://gitlab.example.com --oauth2-id 6a52769e… --oauth2-secret 6b79168f… --dashboard-url dashboard.example.comDet er på tide å gå til dashbordet og finne en ganske arkaisk påloggingsknapp:
Etter å ha klikket på den, vil GitLab hilse på oss, og tilby å logge inn på sin vanlige side (selvfølgelig, hvis vi ikke tidligere har logget på der):
Vi logger inn med GitLab-legitimasjon - og alt er gjort:
Om Dashboard-funksjoner
Hvis du er en utvikler som ikke har jobbet med Kubernetes før, eller rett og slett av en eller annen grunn ikke har støtt på Dashboard før, vil jeg illustrere noen av mulighetene.
For det første kan du se at "alt er grønt":
Mer detaljerte data er også tilgjengelige for pods, for eksempel miljøvariabler, nedlastede bilder, lanseringsargumenter og deres tilstand:
Implementeringer har synlige statuser:
...og andre detaljer:
... og det er også muligheten til å skalere distribusjonen:
Resultatet av denne operasjonen:
Blant andre nyttige funksjoner som allerede er nevnt i begynnelsen av artikkelen er visning av logger:
... og funksjonen for å logge på containerkonsollen til den valgte poden:
For eksempel kan du også se på grensene/forespørslene på noder:
Selvfølgelig er ikke dette alle funksjonene til panelet, men jeg håper at du forstår den generelle ideen.
Ulemper med integrasjon og Dashboard
I den beskrevne integrasjonen er det ingen adgangskontroll. Med den får alle brukere med tilgang til GitLab tilgang til Dashboard. De har samme tilgang i selve dashbordet, tilsvarende rettighetene til selve dashbordet, som . Det er klart at dette ikke passer for alle, men for vårt tilfelle viste det seg å være tilstrekkelig.
Blant de merkbare ulempene i selve dashbordet, merker jeg følgende:
- det er umulig å komme inn i konsollen til initbeholderen;
- det er umulig å redigere Deployments og StatefulSets, selv om dette kan fikses i ClusterRole;
- Dashboards kompatibilitet med de nyeste versjonene av Kubernetes og fremtiden til prosjektet reiser spørsmål.
Det siste problemet fortjener spesiell oppmerksomhet.
Dashboardstatus og alternativer
Dashboard-kompatibilitetstabell med Kubernetes-utgivelser, presentert i den nyeste versjonen av prosjektet (), ikke veldig fornøyd:
Til tross for dette er det (allerede vedtatt i januar) , som kunngjør støtte for K8s 1.13. I tillegg kan du blant prosjektsakene finne referanser til brukere som jobber med panelet i K8s 1.14. Endelig, inn i prosjektets kodebase stopper ikke. Så (minst!) den faktiske statusen til prosjektet er ikke så ille som det først kan se ut fra den offisielle kompatibilitetstabellen.
Til slutt er det alternativer til Dashboard. Blant dem:
- — et ungt grensesnitt (de første forpliktelser dateres tilbake til mars i år), som allerede tilbyr gode funksjoner, for eksempel en visuell representasjon av den nåværende statusen til klyngen og administrasjon av objektene. Plassert som et "sanntidsgrensesnitt", fordi oppdaterer automatisk de viste dataene uten at du trenger å oppdatere siden i nettleseren.
- - et nettgrensesnitt fra Red Hat OpenShift, som imidlertid vil bringe andre utviklinger av prosjektet til din klynge, som ikke passer for alle.
- er et interessant prosjekt, laget som et grensesnitt på lavere nivå (enn Dashboard) med muligheten til å se alle klyngeobjekter. Det ser imidlertid ut til at utviklingen har stoppet opp.
- - bare her om dagen et prosjekt som kombinerer funksjonene til et panel (viser den nåværende tilstanden til klyngen, men administrerer ikke objektene) og automatisk "validering av beste praksis" (sjekker klyngen for riktigheten av konfigurasjonene til distribusjoner som kjører i den).
I stedet for konklusjoner
Dashboard er et standardverktøy for Kubernetes-klyngene vi betjener. Integrasjonen med GitLab har også blitt en del av standardinstallasjonen vår, ettersom mange utviklere er begeistret over mulighetene de har med dette panelet.
Kubernetes Dashboard har med jevne mellomrom alternativer fra Open Source-fellesskapet (og vi vurderer dem gjerne), men på dette stadiet forblir vi med denne løsningen.
PS
Les også på bloggen vår:
- «";
- «";
- «";
- «'.
Kilde: www.habr.com