Kubernetes Dashboard — un instrument ușor de utilizat pentru a obține informații actualizate despre cluster-ul activ și pentru a-l gestiona minim. Este apreciat și mai mult atunci când accesul la aceste funcționalități este necesar nu doar administratorilor sau inginerilor DevOps, ci și celor care sunt mai puțin familiarizați cu consola și/sau nu intenționează să se descurce cu toate detaliile interacțiunii cu kubectl și alte utilitare. Aceasta este situația și în cazul nostru: dezvoltatorii au dorit un acces rapid la interfața web Kubernetes, iar având în vedere că folosim GitLab, soluția s-a impus de la sine.
De ce este necesar?
Dezvoltatorii direcți ar putea fi interesați de un instrument precum K8s Dashboard pentru sarcini de depanare. Uneori, este util să vizualizezi jurnalele și resursele, iar alteori, să oprești pod-urile, să scalezi Deployments/StatefulSets și chiar să intri în consola containerelor (există și astfel de cereri, pentru rezolvarea cărora, totuși, există o altă cale — de exemplu, prin ).
În plus, există și un aspect psihologic pentru lideri, când doresc să privească cluster-ul — să vadă că „totul este verde” și astfel să se liniștească, că „totul funcționează” (ceea ce, desigur, este foarte relativ… dar aceasta depășește subiectul articolului).
Ca sistem CI standard, noi GitLab: toți dezvoltatorii se folosesc de el. Prin urmare, pentru a le oferi acces, a fost logic să facem integrarea Dashboard cu conturile din GitLab.
De asemenea, menționez că folosim NGINX Ingress. Dacă lucrați cu alte , va fi necesar să găsiți analogii pentru anotările de autorizare.
Încercăm integrarea
Instalarea Dashboard-ului
Atenție: Dacă aveți de gând să repetați pașii descriși mai jos, vă rugăm să citiți mai întâi până la următorul subtitlu pentru a evita operațiunile inutile.
Deoarece această integrare este utilizată de noi în numeroase instalări, am automatizat instalarea ei. Sursele necesare pentru aceasta sunt publicate într-un . Acestea se bazează pe configurații YAML ușor modificate din , precum și pe un script Bash pentru desfășurarea rapidă.
Scriptul instalează Dashboard-ul în cluster și îl configurează pentru integrarea cu GitLab:
$ .\/ctl.sh
Utilizare: ctl.sh [OPȚIUNE]... --gitlab-url GITLAB_URL --oauth2-id ID --oauth2-secret SECRET --dashboard-url DASHBOARD_URL
Instalați kubernetes-dashboard în cluster-ul Kubernetes.
Argumente obligatorii:
-i, --install instalare în spațiul de nume 'kube-system'
-u, --upgrade actualizează instalarea existentă, va reutiliza parolele și numele gazdelor
-d, --delete elimină totul, inclusiv spațiul de nume
--gitlab-url setați URL-ul GitLab conform schemei (https://gitlab.example.com)
--oauth2-id setați OAUTH2_PROXY_CLIENT_ID din GitLab
--oauth2-secret setați OAUTH2_PROXY_CLIENT_SECRET din GitLab
--dashboard-url setați URL-ul dashboard-ului fără schemă (dashboard.example.com)
Argumente opționale:
-h, --help afișează acest mesajCu toate acestea, înainte de utilizare, trebuie să accesați GitLab: Zona de administrare → Aplicații — și să adăugați o nouă aplicație pentru viitorul panou. Să o numim „kubernetes dashboard”:
În urma adăugării acesteia, GitLab va oferi hash-uri:
Exact acestea sunt folosite ca argumente pentru script. Prin urmare, instalarea arată în felul următor:
$ .\/ctl.sh -i --gitlab-url https://gitlab.example.com --oauth2-id 6a52769e… --oauth2-secret 6b79168f… --dashboard-url dashboard.example.comDupă aceasta, să verificăm că totul a fost pornit:
$ kubectl -n kube-system get pod | egrep '(dash|oauth)'
kubernetes-dashboard-76b55bc9f8-xpncp 1\/1 În funcțiune 0 14s
oauth2-proxy-5586ccf95c-czp2v 1\/1 În funcțiune 0 14sMai devreme sau mai târziu, totul se va porni, totuși autentificarea nu va funcționa imediat! Problema este că în imaginea utilizată (situația este similară în alte imagini) procesul de captare a redirecționării în callback este implementat incorect. Această circumstanță duce la faptul că oauth șterge cookie-ul pe care chiar el (oauth) ni-l oferă…
Problema se rezolvă construind propria imagine oauth cu patch-ul.
Patch-ul pentru oauth și reinstalarea
Pentru aceasta, 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\/\n
EXPOSE 8080 4180
ENTRYPOINT [ "\/bin\/oauth2_proxy" ]
CMD [ "--upstream=http:\/\/0.0.0.0:8080\/", "--http-address=0.0.0.0:4180" ]Iată cum arată patch-ul rd.patch
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 "... rulează teste"
-. /test.sh
+#. /test.sh
-for os in windows linux darwin; do
- echo "... construind v$version pentru $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 "... construind v$version pentru $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 se poate face construcția imaginii și să o ‘push’ în GitLab-ul nostru. În continuare în manifests/kube-dashboard-oauth2-proxy.yaml vom specifica utilizarea imaginii necesare (înlocuiți-o cu a dumneavoastră):
image: docker.io/colemickens/oauth2_proxy:latestDacă aveți un registry protejat prin autentificare — nu uitați să adăugați utilizarea secretului pentru pull-ul imaginilor:
imagePullSecrets:
- name: gitlab-registry… și adăugați secretul în sine pentru registry:
---
apiVersion: v1
data:
.dockercfg: eyJyZWdpc3RyeS5jb21wYW55LmNvbSI6IHsKICJ1c2VybmFtZSI6ICJvYXV0aDIiLAogInBhc3N3b3JkIjogIlBBU1NXT1JEIiwKICJhdXRoIjogIkFVVEhfVE9LRU4iLAogImVtYWlsIjogIm1haWxAY29tcGFueS5jb20iCn0KfQoK
=
kind: Secret
metadata:
annotations:
name: gitlab-registry
namespace: kube-system
type: kubernetes.io/dockercfgCititorul atent va observa că lungimea stringului prezentat mai sus este un base64 al configului:
{"registry.company.com": {
"username": "oauth2",
"password": "PASSWORD",
"auth": "AUTH_TOKEN",
"email": "mail@company.com"
}
}Acestea sunt datele utilizatorului în GitLab, cu ajutorul cărora Kubernetes va pull-ui imaginea din registry.
După ce totul este finalizat, puteți să ștergeți actuala instalare (care nu funcționează corect) a Dashboard-ului cu comanda:
$ ./ctl.sh -d… și să instalați totul din nou:
$ .\/ctl.sh -i --gitlab-url https://gitlab.example.com --oauth2-id 6a52769e… --oauth2-secret 6b79168f… --dashboard-url dashboard.example.comA venit timpul să intrăm în Dashboard și să găsim butonul de autentificare destul de arhaic:
După ce dăm clic pe acesta, ne va întâmpina GitLab, oferindu-ne să ne autentificăm pe pagina sa obișnuită (desigur, dacă nu am fost autentificați anterior acolo):
Ne autentificăm cu datele de acreditive GitLab — și totul a fost realizat:
Despre posibilitățile Dashboard-ului
Dacă ești un dezvoltator care nu a lucrat până acum cu Kubernetes, sau din diverse motive nu ai avut contact cu Dashboard până acum, voi ilustra câteva dintre funcționalitățile sale.
În primul rând, poți observa că „totul este verde”:
Pentru poduri sunt disponibile date mai detaliate, cum ar fi variabilele de mediu, imaginea descărcată, argumentele de start, starea acestora:
Pentru deployment-uri se văd statusurile:
… și alte detalii:
… precum și posibilitatea de a scala deployment-ul:
Rezultatul acestei operațiuni:
Printre celelalte funcționalități utile, menționate la începutul articolului, se numără vizualizarea jurnalelor:
… și funcția de acces în consola containerelor pentru podul selectat:
De asemenea, poți vizualiza și limitările/cererile de pe noduri:
Desigur, acestea nu sunt toate funcționalitățile panelului, dar sper că ai o imagine de ansamblu.
Dezavantaje ale integrării și Dashboard-ului
În integrarea descrisă nu există nicio delimitare a accesului. Astfel, toți utilizatorii care au acces la GitLab obțin acces în Dashboard. Accesul în Dashboard este același pentru toți, corespunzător drepturilor panelului, care . Evident, acest lucru nu se potrivește tuturor, dar s-a dovedit a fi suficient pentru cazul nostru.
Printre dezavantajele notabile ale panelului Dashboard, subliniez următoarele:
- nu poți accesa consola init-container;
- nu poți edita Deployments și StatefulSets, deși acest lucru poate fi corectat î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ă.
Statutul și alternativele Dashboard-ului
Tabelul de compatibilitate al Dashboard-ului cu versiunile Kubernetes, prezentat în cea mai recentă versiune a proiectului (), nu este foarte încurajator:
În ciuda acestui lucru, există (aprobat în ianuarie) , care anunță suportul pentru K8s 1.13. În plus, printre problemele proiectului se găsesc mențiuni de utilizatori care lucrează cu panelul în K8s 1.14. În cele din urmă, în base-ul de cod al proiectului nu se opresc. Așa că (cel puțin!) statusul efectiv al proiectului nu este atât de prost pe cât ar putea părea la prima vedere din tabelul oficial de compatibilitate.
În cele din urmă, Dashboard-ul are alternative. Printre acestea:
- — o interfață tânără (primele commit-uri datează din martie anul acesta), care oferă deja posibilități interesante, precum reprezentarea vizuală a stării curente a clusterului și gestionarea obiectelor sale. Se poziționează ca un «interfață în timp real», deoarece actualizează automat datele afișate, fără a necesita reîncărcarea paginii în browser.
- — interfața web de la Red Hat OpenShift, care, totuși, va aduce în clusterul dumneavoastră și alte realizări ale proiectului, ceea ce poate să nu fie potrivit pentru toată lumea.
- — un proiect interesant, creat ca o interfață mai la nivel inferior (decât Dashboard) cu posibilitatea de a vizualiza toate obiectele clusterului. Totuși, arată că dezvoltarea sa a fost suspendată.
- — anunțat acum câteva zile un proiect care combină funcțiile unui panou (arată starea curentă a clusterului, dar nu gestionează obiectele acestuia) și al „validării automate a celor mai bune practici” (verifică clusterul pentru corectitudinea configurațiilor desfășurate în el Deployments).
În loc de concluzii
Dashboard — instrumentul standard pentru clusterele Kubernetes pe care le gestionăm. Integrarea sa cu GitLab a devenit de asemenea parte a «instalării noastre implicite», deoarece mulți dezvoltatori se bucură de oportunitățile oferite de acest panou.
Alternativa Kubernetes Dashboard apare periodic din partea comunității Open Source (și suntem încântați să le luăm în considerare), dar în acest moment rămânem cu această soluție.
P.S.
Citiți și în blogul nostru:
- «»;
- «»;
- «»;
- «».
Sursa: habr.com
