Kubernetes Dashboard eta GitLab erabiltzaileen integrazioa

Kubernetes Dashboard eta GitLab erabiltzaileen integrazioa

Kubernetes Dashboard tresna erabilerraza da zure kluster exekutatzen ari den informazio eguneratua lortzeko eta gutxieneko esfortzuarekin kudeatzeko. Are gehiago estimatzen hasten zara gaitasun horietarako sarbidea administratzaile/DevOps ingeniariek ez ezik, kontsolarekin hain ohituta daudenek eta/edo kubectl eta kubectl-ekin elkarreraginaren zailtasun guztiei aurre egiteko asmorik ez dutenek ere. beste utilitate batzuk. Hori gertatu zen gurekin: garatzaileek Kubernetes web-interfazerako sarbide azkarra nahi zuten, eta GitLab erabiltzen dugunez, irtenbidea berez etorri zen.

Zergatik da hau?

Garatzaile zuzenek K8s Dashboard bezalako tresna batean interesa izan dezakete arazketa-zereginetarako. Batzuetan, erregistroak eta baliabideak ikusi nahi dituzu, eta beste batzuetan lekak hil, Inplementazioak/StatefulSets eskalatu eta edukiontzien kontsolara ere joan nahi dituzu (eskaerak ere badaude, eta, hala ere, beste modu bat dago, adibidez, bidez. kubectl-araztea).

Horrez gain, kudeatzaileek klusterrera begiratu nahi dutenean une psikologiko bat dago –«dena berdeaΒ» dela ikustea, eta, horrela, Β«dena funtzionatzen ari delaΒ» ziurtatzeko (oso erlatiboa, noski...). baina hau artikuluaren esparrutik kanpo dago).

CI sistema estandar gisa daukagu aplikatuta GitLab: garatzaile guztiek ere erabiltzen dute. Hori dela eta, sarbidea emateko, logikoa zen Dashboard GitLab kontuekin integratzea.

NGINX Ingress erabiltzen dugula ere ohartuko naiz. Besteekin lan egiten baduzu sarrerako irtenbideak, baimena lortzeko oharpenen analogoak modu independentean aurkitu beharko dituzu.

Integrazioa saiatzen

Arbelaren instalazioa

Arreta: Beheko pausoak errepikatuko badituzu, orduan - alferrikako eragiketak saihesteko - irakurri lehenik hurrengo azpititulara.

Instalazio askotan integrazio hau erabiltzen dugunez, bere instalazioa automatizatu dugu. Horretarako behar diren iturriak urtean argitaratu dira GitHub biltegi berezia. Apur bat aldatutako YAML konfigurazioetan oinarritzen dira Dashboard biltegi ofiziala, baita inplementazio azkarra egiteko Bash script bat ere.

Scriptak Dashboard klusterrean instalatzen du eta GitLab-ekin integratzeko konfiguratzen du:

$ ./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

Hala ere, erabili aurretik, GitLab-era joan behar duzu: Admin area β†’ Aplikazioak - eta aplikazio berri bat gehitu etorkizuneko panelerako. Dei diezaiogun "kubernetes panela":

Kubernetes Dashboard eta GitLab erabiltzaileen integrazioa

Gehitzearen ondorioz, GitLab-ek hashak emango ditu:

Kubernetes Dashboard eta GitLab erabiltzaileen integrazioa

Gidoiaren argudio gisa erabiltzen direnak dira. Ondorioz, instalazioa honelakoa da:

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

Horren ondoren, egiaztatu dezagun dena hasi zela:

$ 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

Lehenago edo beranduago dena hasiko da, ordea baimenak ez du berehala funtzionatuko! Kontua da erabilitako irudian (beste irudietan egoera antzekoa da) dei-itzuleran birbideratze-prozesua gaizki inplementatzen dela. Zirkunstantzia honek oauth-ek oauth-ek berak ematen digun cookiea ezabatzen du...

Arazoa zure oauth irudia adabaki batekin eraikiz konpontzen da.

Adabaki oauth eta berriro instalatu

Horretarako, Dockerfile hau erabiliko dugu:

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

Eta hona hemen rd.patch adabakia bera nolakoa den

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

Orain irudia eraiki dezakezu eta gure GitLab-era eraman dezakezu. Hurrengoan manifests/kube-dashboard-oauth2-proxy.yaml adierazi nahi den irudiaren erabilera (ordeztu zurearekin):

 image: docker.io/colemickens/oauth2_proxy:latest

Baimenduz itxita dagoen erregistro bat baduzu, ez ahaztu tira irudietarako sekretu baten erabilera gehitzea:

      imagePullSecrets:
     - name: gitlab-registry

... eta gehitu sekretua bera erregistrorako:

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

Irakurle adiak goiko kate luzea base64 dela ikusiko du konfiguraziotik:

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

Hau GitLab-eko erabiltzailearen datuak dira, Kubernetes kodeak erregistrotik aterako du irudia.

Dena egin ondoren, uneko Arbelaren instalazioa kendu dezakezu (ez da behar bezala funtzionatzen) komandoarekin:

$ ./ctl.sh -d

... eta berriro instalatu dena:

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

Dashboard-era joan eta saioa hasteko botoi nahiko arkaiko bat aurkitzeko garaia da:

Kubernetes Dashboard eta GitLab erabiltzaileen integrazioa

Bertan klik egin ondoren, GitLab-ek agurtuko gaitu, bere ohiko orrialdean saioa hasteko eskainiz (noski, aldez aurretik bertan sartu ez bagara):

Kubernetes Dashboard eta GitLab erabiltzaileen integrazioa

GitLab kredentzialekin hasten gara saioa eta dena eginda dago:

Kubernetes Dashboard eta GitLab erabiltzaileen integrazioa

Arbelaren eginbideei buruz

Aurretik Kubernetesekin lan egin ez duen garatzailea bazara edo, besterik gabe, arrazoiren batengatik aurretik Dashboard-a topatu ez baduzu, bere gaitasun batzuk azalduko ditut.

Lehenik eta behin, "dena berdea" dela ikus dezakezu:

Kubernetes Dashboard eta GitLab erabiltzaileen integrazioa

Datu zehatzagoak ere eskuragarri daude leketarako, hala nola ingurune-aldagaiak, deskargatutako irudia, abiarazteko argumentuak eta haien egoera:

Kubernetes Dashboard eta GitLab erabiltzaileen integrazioa

Inplementazioek egoera ikusgaiak dituzte:

Kubernetes Dashboard eta GitLab erabiltzaileen integrazioa

...eta beste xehetasun batzuk:

Kubernetes Dashboard eta GitLab erabiltzaileen integrazioa

... eta hedapena eskalatzeko gaitasuna ere badago:

Kubernetes Dashboard eta GitLab erabiltzaileen integrazioa

Eragiketa honen emaitza:

Kubernetes Dashboard eta GitLab erabiltzaileen integrazioa

Artikuluaren hasieran aipatutako beste ezaugarri erabilgarri batzuen artean erregistroak ikustea dago:

Kubernetes Dashboard eta GitLab erabiltzaileen integrazioa

... eta hautatutako podaren edukiontzi-kontsolan saioa hasteko funtzioa:

Kubernetes Dashboard eta GitLab erabiltzaileen integrazioa

Adibidez, nodoetako mugak/eskaerak ere ikus ditzakezu:

Kubernetes Dashboard eta GitLab erabiltzaileen integrazioa

Jakina, hauek ez dira panelaren gaitasun guztiak, baina ideia orokorra jasotzea espero dut.

Integrazioaren eta Arbelaren desabantailak

Deskribatutako integrazioan ez dago sarbide kontrola. Horrekin, GitLab-en edozein sarbide duten erabiltzaile guztiek Arbelerako sarbidea dute. Sarbide bera dute Arbelean bertan, Arbelaren beraren eskubideei dagozkienak, zeina RBAC-en definitzen dira. Jakina, hau ez da guztientzako egokia, baina gure kasuan nahikoa izan da.

Arbelean bertan dauden desabantaila nabarmenen artean, honako hauek nabarmentzen ditut:

  • ezinezkoa da init edukiontziaren kontsolara sartzea;
  • ezinezkoa da Deployments eta StatefulSets editatzea, nahiz eta hori ClusterRole-n konpondu daitekeen;
  • Dashboard-ek Kubernetes-en azken bertsioekin duen bateragarritasuna eta proiektuaren etorkizuna zalantzak sortzen ditu.

Azken arazoak arreta berezia merezi du.

Arbelaren egoera eta alternatibak

Kubernetes-en bertsioekin panelen bateragarritasun-taula, proiektuaren azken bertsioan aurkeztua (v1.10.1), ez oso pozik:

Kubernetes Dashboard eta GitLab erabiltzaileen integrazioa

Hala ere, badago (dagoeneko urtarrilean onartua) PR # 3476, K8s 1.13rako laguntza iragartzen duena. Horrez gain, proiektuaren gaien artean panelarekin lan egiten duten erabiltzaileen erreferentziak aurki ditzakezu K8s 1.14. Azkenik, konpromisoa hartzen du proiektuaren kode oinarrian sartu ez gelditu. Beraz, (gutxienez!) proiektuaren benetako egoera ez da bateragarritasun-taula ofizialean dirudien bezain txarra.

Azkenik, Dashboard-en alternatibak daude. Haien artean:

  1. K8Dash β€” interfaze gazte bat (lehen konpromisoak aurtengo martxokoak dira), dagoeneko ezaugarri onak eskaintzen dituena, hala nola klusterren egungo egoeraren irudikapen bisuala eta bere objektuen kudeaketa. "Denbora errealeko interfaze" gisa kokatuta, zeren automatikoki eguneratzen ditu bistaratutako datuak arakatzailean orria freskatu beharrik gabe.
  2. OpenShift kontsola - Red Hat OpenShift-en web-interfaze bat, eta, hala ere, proiektuaren beste garapen batzuk ekarriko ditu zure klusterera, ez denentzat egokia.
  3. Kubernator proiektu interesgarria da, maila baxuagoko (Arbela baino) interfaze gisa sortua, kluster objektu guztiak ikusteko gaitasuna duena. Hala ere, badirudi bere garapena gelditu egin dela.
  4. Polaris - Beste egunean iragarri panel baten funtzioak (klusterren uneko egoera erakusten du, baina ez ditu bere objektuak kudeatzen) eta "praktika egokien baliozkotze" automatikoa (klusterrak bertan exekutatzen diren Inplementazioen konfigurazioen zuzentasuna egiaztatzen du) konbinatzen dituen proiektua.

Ondorioen ordez

Arbel tresna estandar bat da zerbitzatzen ditugun Kubernetes klusterretarako. GitLab-ekin duen integrazioa gure instalazio lehenetsiaren parte bihurtu da, garatzaile asko panel honekin dituzten gaitasunekin ilusioz baitaude.

Kubernetes Dashboard-ek aldian-aldian Iturburu Irekiko komunitatearen alternatibak ditu (eta pozik hartzen ditugu kontuan), baina fase honetan irtenbide honekin jarraitzen dugu.

PS

Irakurri ere gure blogean:

Iturria: www.habr.com

Gehitu iruzkin berria