Integrarea Kubernetes Dashboard și utilizatorii GitLab

Kubernetes Dashboard este un instrument ușor de utilizat pentru a obține informații actualizate despre clusterul dvs. care rulează și pentru a-l gestiona cu efort minim. Începi să apreciezi și mai mult atunci când accesul la aceste capabilități este nevoie nu numai de administratori/inginerii DevOps, ci și de cei care sunt mai puțin obișnuiți cu consola și/sau nu intenționează să se ocupe de toate complexitățile interacțiunii cu kubectl și alte utilitati. Acest lucru s-a întâmplat cu noi: dezvoltatorii doreau acces rapid la interfața web Kubernetes și, din moment ce folosim GitLab, soluția a venit de la sine.

De ce asta?

Dezvoltatorii direcți pot fi interesați de un instrument precum K8s Dashboard pentru sarcinile de depanare. Uneori doriți să vizualizați jurnalele și resursele și, uneori, să ucideți poduri, să scalați Implementări/StatefulSets și chiar să mergeți la consola containerului (există și solicitări pentru care, totuși, există o altă cale - de exemplu, prin kubectl-debug).

În plus, există un moment psihologic pentru manageri când vor să se uite la cluster - să vadă că „totul este verde”, și astfel să se asigure că „totul funcționează” (ceea ce, desigur, este foarte relativ... dar acest lucru depășește domeniul de aplicare al articolului).

Ca sistem CI standard avem aplica GitLab: toți dezvoltatorii îl folosesc și ei. Prin urmare, pentru a le oferi acces, era logic să se integreze Dashboard cu conturile GitLab.

Voi observa, de asemenea, că folosim NGINX Ingress. Dacă lucrezi cu alții soluții de intrare, va trebui să găsiți în mod independent analogi de adnotări pentru autorizare.

Încercarea de integrare

Instalarea tabloului de bord

Atenție: Dacă urmează să repetați pașii de mai jos, atunci - pentru a evita operațiunile inutile - citiți mai întâi la următorul subtitlu.

Deoarece folosim această integrare în multe instalații, am automatizat instalarea acesteia. Sursele necesare pentru aceasta sunt publicate în depozit special GitHub. Ele se bazează pe configurații YAML ușor modificate din depozitul oficial de tablou de bord, precum și un script Bash pentru implementare rapidă.

Scriptul instalează Dashboard în cluster și îl configurează pentru integrarea cu 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

Cu toate acestea, înainte de a-l folosi, trebuie să mergeți la GitLab: Zona de administrare → Aplicații - și să adăugați o nouă aplicație pentru viitorul panou. Să-i spunem „tabloul de bord kubernetes”:

Ca urmare a adăugării acestuia, GitLab va furniza hash-urile:

Ele sunt cele care sunt folosite ca argumente pentru scenariu. Ca urmare, instalarea arată astfel:

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

După aceea, să verificăm dacă totul a început:

$ 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

Totuși, mai devreme sau mai târziu, totul va începe autorizația nu va funcționa imediat! Cert este că în imaginea folosită (situația în alte imagini este similară) procesul de captare a unei redirecționări în callback este implementat incorect. Această împrejurare duce la faptul că oauth șterge cookie-ul pe care oauth însuși ni-l oferă...

Problema este rezolvată prin construirea propriei imagini de oauth cu un patch.

Corectați oauth și reinstalați

Pentru a face acest lucru, vom folosi următorul 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" ]

Și iată cum arată patch-ul rd.patch în sine

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

Acum puteți construi imaginea și o puteți introduce în GitLab. Următorul în manifests/kube-dashboard-oauth2-proxy.yaml indicați utilizarea imaginii dorite (înlocuiți-o cu propria dvs.):

 image: docker.io/colemickens/oauth2_proxy:latest

Dacă aveți un registru care este închis prin autorizare, nu uitați să adăugați utilizarea unui secret pentru imaginile de extragere:

      imagePullSecrets:
     - name: gitlab-registry

... și adăugați secretul în sine pentru registru:

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

Cititorul atent va vedea că șirul lung de mai sus este base64 din configurație:

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

Acestea sunt datele utilizatorului din GitLab, codul Kubernetes va scoate imaginea din registry.

După ce totul este făcut, puteți elimina instalarea curentă (nu funcționează corect) a tabloului de bord cu comanda:

$ ./ctl.sh -d

... și instalează totul din nou:

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

Este timpul să mergeți la Tabloul de bord și să găsiți un buton de conectare destul de arhaic:

După ce facem clic pe el, GitLab ne va saluta, oferindu-ne să ne autentificăm la pagina sa obișnuită (desigur, dacă nu ne-am autentificat anterior acolo):

Ne autentificăm cu acreditările GitLab - și totul este gata:

Despre funcțiile tabloului de bord

Dacă sunteți un dezvoltator care nu a mai lucrat cu Kubernetes sau pur și simplu, dintr-un motiv oarecare, nu ați întâlnit Dashboard înainte, voi ilustra câteva dintre capacitățile acestuia.

În primul rând, puteți vedea că „totul este verde”:

Sunt disponibile și date mai detaliate pentru poduri, cum ar fi variabilele de mediu, imaginea descărcată, argumentele de lansare și starea acestora:

Implementările au stări vizibile:

...si alte detalii:

... și există, de asemenea, capacitatea de a scala implementarea:

Rezultatul acestei operațiuni:

Printre alte caracteristici utile menționate deja la începutul articolului este vizualizarea jurnalelor:

... și funcția de autentificare în consola container a podului selectat:

De exemplu, puteți să vă uitați și la limitele/cererile pe noduri:

Desigur, acestea nu sunt toate capabilitățile panoului, dar sper că vă faceți o idee generală.

Dezavantajele integrării și tabloului de bord

În integrarea descrisă nu există controlul accesului. Cu acesta, toți utilizatorii cu orice acces la GitLab obțin acces la tabloul de bord. Ei au același acces în tabloul de bord propriu-zis, corespunzătoare drepturilor însuși tabloul de bord, care sunt definite în RBAC. Evident, acest lucru nu este potrivit pentru toată lumea, dar pentru cazul nostru s-a dovedit a fi suficient.

Printre dezavantajele vizibile din tabloul de bord în sine, remarc următoarele:

• este imposibil să intri în consola containerului init;
• este imposibil să editați Deployments și StatefulSets, deși acest lucru poate fi remediat în ClusterRole;
• Compatibilitatea Dashboard-ului cu cele mai recente versiuni de Kubernetes și viitorul proiectului ridică întrebări.

Ultima problemă merită o atenție specială.

Starea tabloului de bord și alternative

Tabelul de compatibilitate a tabloului de bord cu versiunile Kubernetes, prezentat în cea mai recentă versiune a proiectului (v1.10.1), nu foarte fericit:

În ciuda acestui fapt, există (deja adoptat în ianuarie) PR #3476, care anunță suport pentru K8s 1.13. În plus, printre problemele proiectului puteți găsi referințe la utilizatorii care lucrează cu panoul în K8s 1.14. In cele din urma, comite în baza de cod a proiectului nu se oprește. Deci (cel puțin!) starea reală a proiectului nu este atât de rău pe cât ar putea părea la început din tabelul oficial de compatibilitate.

În cele din urmă, există alternative la Dashboard. Printre ei:

1. K8Dash — o interfață tânără (primele angajamente datează din luna martie a acestui an), care oferă deja caracteristici bune, cum ar fi o reprezentare vizuală a stării actuale a clusterului și managementul obiectelor acestuia. Poziționată ca o „interfață în timp real”, deoarece actualizează automat datele afișate fără a fi necesar să reîmprospătați pagina în browser.
2. Consola OpenShift - o interfață web de la Red Hat OpenShift, care, totuși, va aduce în clusterul dvs. alte dezvoltări ale proiectului, care nu este potrivită pentru toată lumea.
3. Kubernator este un proiect interesant, creat ca o interfață de nivel inferior (decât Dashboard) cu capacitatea de a vizualiza toate obiectele cluster. Cu toate acestea, se pare că dezvoltarea sa s-a oprit.
4. Polaris - chiar zilele trecute a anunțat un proiect care combină funcțiile unui panou (afișează starea curentă a clusterului, dar nu gestionează obiectele acestuia) și „validarea celor mai bune practici” automată (verifică clusterul pentru corectitudinea configurațiilor Deployment-urilor care rulează în el).

În loc de concluzii

Tabloul de bord este un instrument standard pentru clusterele Kubernetes pe care le servim. Integrarea sa cu GitLab a devenit, de asemenea, parte a instalării noastre implicite, deoarece mulți dezvoltatori sunt încântați de capabilitățile pe care le au cu acest panou.

Kubernetes Dashboard are periodic alternative din comunitatea Open Source (și suntem bucuroși să le luăm în considerare), dar în acest stadiu rămânem cu această soluție.

PS

Citește și pe blogul nostru:

• «kubebox și alte shell-uri pentru Kubernetes»;
• «Cele mai bune practici CI/CD cu Kubernetes și GitLab (recenzie și raport video)»;
• «Creați și implementați aplicații în Kubernetes folosind dapp și GitLab CI»;
• «GitLab CI pentru integrare și livrare continuă în producție. Partea 1: conducta noastră".

Sursa: www.habr.com