Integrasie van Kubernetes Dashboard en GitLab-gebruikers

Kubernetes Dashboard is 'n maklik-om-te gebruik hulpmiddel om bygewerkte inligting oor jou lopende groepering te kry en dit met minimale moeite te bestuur. Jy begin dit selfs meer waardeer wanneer toegang tot hierdie vermoëns benodig word nie net deur administrateurs/DevOps-ingenieurs nie, maar ook deur diegene wat minder gewoond is aan die konsole en/of nie van plan is om al die ingewikkeldhede van interaksie met kubectl en te hanteer nie. ander nutsdienste. Dit het met ons gebeur: die ontwikkelaars wou vinnige toegang tot die Kubernetes-webkoppelvlak hê, en aangesien ons GitLab gebruik, het die oplossing natuurlik gekom.

Hoekom is dit?

Direkte ontwikkelaars kan belangstel in 'n instrument soos K8s Dashboard vir ontfoutingstake. Soms wil jy logs en hulpbronne bekyk, en soms pods doodmaak, Ontplooiings/StatefulSets skaal, en selfs na die houerkonsole gaan (daar is ook versoeke waarvoor daar egter 'n ander manier is - byvoorbeeld deur kubectl-ontfout).

Boonop is daar 'n sielkundige oomblik vir bestuurders wanneer hulle na die cluster wil kyk - om te sien dat "alles groen is", en sodoende hulself verseker dat "alles werk" (wat natuurlik baie relatief is... maar dit is buite die bestek van die artikel).

As 'n standaard CI-stelsel het ons toegepas GitLab: alle ontwikkelaars gebruik dit ook. Om hulle toegang te gee, was dit dus logies om Dashboard met GitLab-rekeninge te integreer.

Ek sal ook daarop let dat ons NGINX Ingress gebruik. As jy saam met ander werk oplossings binnedring, sal jy onafhanklik analoë van annotasies moet vind vir magtiging.

Probeer integrasie

Dashboard installasie

Aandag: As jy die stappe hieronder gaan herhaal, lees dan - om onnodige bewerkings te vermy - eers na die volgende subopskrif.

Aangesien ons hierdie integrasie in baie installasies gebruik, het ons die installasie daarvan geoutomatiseer. Die bronne wat hiervoor benodig word, word gepubliseer in spesiale GitHub-bewaarplek. Hulle is gebaseer op effens gewysigde YAML-konfigurasies vanaf amptelike Dashboard-bewaarplek, sowel as 'n Bash-skrif vir vinnige ontplooiing.

Die skrip installeer Dashboard in die cluster en stel dit op vir integrasie met 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

Voordat u dit egter gebruik, moet u na GitLab gaan: Admin-area → Toepassings - en 'n nuwe toepassing vir die toekomstige paneel byvoeg. Kom ons noem dit "kubernetes dashboard":

As gevolg van die byvoeging, sal GitLab die hashes verskaf:

Dit is diegene wat as argumente vir die skrif gebruik word. As gevolg hiervan lyk die installasie soos volg:

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

Kom ons kyk daarna dat alles begin het:

$ 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

Vroeër of later sal alles egter begin magtiging sal nie onmiddellik werk nie! Die feit is dat in die beeld wat gebruik word (die situasie in ander beelde is soortgelyk) die proses om 'n aanstuur in die terugbel te vang, verkeerd geïmplementeer word. Hierdie omstandigheid lei daartoe dat oauth die koekie wat oauth self aan ons verskaf uitvee...

Die probleem word opgelos deur jou eie oauth-beeld met 'n pleister te bou.

Patch oauth en herinstalleer

Om dit te doen, sal ons die volgende Dockerfile gebruik:

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" ]

En hier is hoe die rd.patch-pleister self lyk

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

Nou kan jy die prent bou en dit in ons GitLab druk. Volgende in manifests/kube-dashboard-oauth2-proxy.yaml dui die gebruik van die verlangde prent aan (vervang dit met jou eie):

 image: docker.io/colemickens/oauth2_proxy:latest

As u 'n register het wat deur magtiging gesluit is, moenie vergeet om die gebruik van 'n geheim vir trekprente by te voeg nie:

      imagePullSecrets:
     - name: gitlab-registry

... en voeg die geheim self by vir die register:

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

Die aandagtige leser sal sien dat die lang string hierbo base64 is vanaf die konfigurasie:

{"registry.company.com": {
 "username": "oauth2",
 "password": "PASSWORD",
 "auth": "AUTH_TOKEN",
 "email": "[email protected]"
}
}

Dit is die gebruikersdata in GitLab, die Kubernetes-kode sal die prent uit die register trek.

Nadat alles gedoen is, kan jy die huidige (nie reg werk nie) Dashboard-installasie verwyder met die opdrag:

$ ./ctl.sh -d

... en installeer alles weer:

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

Dit is tyd om na die Dashboard te gaan en 'n taamlik argaïese aanmeldknoppie te vind:

Nadat ons daarop geklik het, sal GitLab ons groet en aanbied om by sy gewone bladsy aan te meld (natuurlik, as ons nie voorheen daar aangemeld het nie):

Ons meld aan met GitLab-geloofsbriewe - en alles is gedoen:

Oor Dashboard-kenmerke

As jy 'n ontwikkelaar is wat nog nie voorheen met Kubernetes gewerk het nie, of bloot om een ​​of ander rede nie Dashboard voorheen teëgekom het nie, sal ek sommige van sy vermoëns illustreer.

Eerstens kan jy sien dat "alles groen is":

Meer gedetailleerde data is ook beskikbaar vir peule, soos omgewingsveranderlikes, afgelaaide beeld, bekendstellingsargumente en hul toestand:

Ontplooiings het sigbare statusse:

...en ander besonderhede:

... en daar is ook die vermoë om die ontplooiing te skaal:

Die resultaat van hierdie operasie:

Onder ander nuttige kenmerke wat reeds aan die begin van die artikel genoem is, is om logs te sien:

... en die funksie om by die houerkonsole van die geselekteerde peul aan te meld:

U kan byvoorbeeld ook na die limiete/versoeke op nodusse kyk:

Dit is natuurlik nie al die vermoëns van die paneel nie, maar ek hoop dat jy die algemene idee kry.

Nadele van integrasie en Dashboard

In die beskryfde integrasie is daar geen toegangsbeheer. Daarmee kry alle gebruikers met enige toegang tot GitLab toegang tot die Dashboard. Hulle het dieselfde toegang in die Dashboard self, wat ooreenstem met die regte van die Dashboard self, wat word in RBAC gedefinieer. Dit is natuurlik nie geskik vir almal nie, maar vir ons geval was dit voldoende.

Onder die merkbare nadele in die Dashboard self, let ek op die volgende:

• dit is onmoontlik om in die konsole van die inithouer te kom;
• dit is onmoontlik om Ontplooiings en StatefulSets te wysig, alhoewel dit in ClusterRole reggestel kan word;
• Dashboard se verenigbaarheid met die nuutste weergawes van Kubernetes en die toekoms van die projek laat vrae ontstaan.

Die laaste probleem verdien spesiale aandag.

Dashboardstatus en alternatiewe

Dashboard-versoenbaarheidstabel met Kubernetes-vrystellings, aangebied in die nuutste weergawe van die projek (v1.10.1), nie baie gelukkig nie:

Ten spyte hiervan is daar (reeds in Januarie aangeneem) PR # 3476, wat ondersteuning vir K8s 1.13 aankondig. Daarbenewens kan u onder die projekkwessies verwysings vind na gebruikers wat met die paneel werk in K8s 1.14. Uiteindelik, pleeg in die projek se kodebasis stop nie. So (ten minste!) is die werklike status van die projek nie so erg soos wat dit eers uit die amptelike versoenbaarheidstabel mag lyk nie.

Ten slotte is daar alternatiewe vir Dashboard. Tussen hulle:

1. K8Dash — 'n jong koppelvlak (die eerste commits dateer terug na Maart vanjaar), wat reeds goeie kenmerke bied, soos 'n visuele voorstelling van die huidige status van die groepering en die bestuur van sy voorwerpe. Geposisioneer as 'n "intydse koppelvlak", want werk die vertoonde data outomaties op sonder dat u die bladsy in die blaaier moet verfris.
2. OpenShift-konsole - 'n webkoppelvlak van Red Hat OpenShift, wat egter ander ontwikkelings van die projek na jou groep sal bring, wat nie vir almal geskik is nie.
3. Kubernator is 'n interessante projek, geskep as 'n laer vlak (as Dashboard) koppelvlak met die vermoë om alle trosvoorwerpe te sien. Dit lyk egter of die ontwikkeling daarvan gestop het.
4. Polaris - net die ander dag aangekondig 'n projek wat die funksies van 'n paneel kombineer (toon die huidige toestand van die groepering, maar bestuur nie sy voorwerpe nie) en outomatiese "validering van beste praktyke" (kontroleer die groepering vir die korrektheid van die konfigurasies van Ontplooiings wat daarin loop).

In plaas van gevolgtrekkings

Dashboard is 'n standaardhulpmiddel vir die Kubernetes-klusters wat ons bedien. Die integrasie daarvan met GitLab het ook deel van ons verstekinstallasie geword, aangesien baie ontwikkelaars opgewonde is oor die vermoëns wat hulle met hierdie paneel het.

Kubernetes Dashboard het periodiek alternatiewe van die Open Source-gemeenskap (en ons oorweeg dit graag), maar op hierdie stadium bly ons by hierdie oplossing.

PS

Lees ook op ons blog:

• «kubebox en ander skulpe vir Kubernetes»;
• «Beste CI/CD-praktyke met Kubernetes en GitLab (resensie- en videoverslag)»;
• «Bou en ontplooi toepassings in Kubernetes met behulp van dapp en GitLab CI»;
• «GitLab CI vir deurlopende integrasie en aflewering in produksie. Deel 1: ons pyplyn".

Bron: will.com