Integracija Kubernetes Dashboard i GitLab korisnika

Kubernetes Dashboard je alat lak za korištenje za dobivanje ažuriranih informacija o vašem pokrenutom klasteru i upravljanje njime uz minimalan napor. Počinjete još više cijeniti kada pristup ovim funkcijama nije potreban samo administratorima/DevOps inženjerima, već i onima koji su manje navikli na konzolu i/ili ne namjeravaju da se bave svim zamršenostima interakcije sa kubectl i ostale komunalne usluge. To se dogodilo i kod nas: programeri su željeli brz pristup Kubernetes web sučelju, a pošto koristimo GitLab, rješenje je došlo prirodno.

Zašto je ovo?

Direktni programeri mogu biti zainteresirani za alat kao što je K8s Dashboard za zadatke otklanjanja grešaka. Ponekad želite da pregledate zapisnike i resurse, a ponekad da ubijete podove, skalirate Deployments/StatefulSets, pa čak i da odete na konzolu kontejnera (postoje i zahtevi za koje, međutim, postoji drugi način - na primer, preko kubectl-debug).

Osim toga, postoji psihološki momenat za menadžere kada žele da pogledaju klaster – da vide da je „sve zeleno“, i tako sebe uvere da „sve funkcioniše“ (što je, naravno, veoma relativno... ali to je izvan okvira članka).

Kao standardni CI sistem imamo se primjenjuje GitLab: koriste ga i svi programeri. Stoga, da bi im se omogućio pristup, bilo je logično integrirati Dashboard sa GitLab nalozima.

Također ću napomenuti da koristimo NGINX Ingress. Ako radite sa drugima ulazna rješenja, morat ćete samostalno pronaći analoge napomena za autorizaciju.

Pokušavam sa integracijom

Instalacija kontrolne table

Oprez: Ako ćete ponoviti donje korake, onda - da biste izbjegli nepotrebne operacije - prvo pročitajte sljedeći podnaslov.

Budući da ovu integraciju koristimo u mnogim instalacijama, automatizirali smo njenu instalaciju. Izvori potrebni za to su objavljeni u posebno GitHub spremište. Zasnovani su na malo izmijenjenim YAML konfiguracijama iz službeni repozitorij Dashboard, kao i Bash skriptu za brzu implementaciju.

Skripta instalira Dashboard u klaster i konfiguriše ga za integraciju sa GitLabom:

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

Međutim, prije nego što ga koristite, morate otići na GitLab: Administrativno područje → Aplikacije - i dodati novu aplikaciju za budući panel. Nazovimo to "kubernetes kontrolna tabla":

Kao rezultat njegovog dodavanja, GitLab će osigurati hasheve:

Oni se koriste kao argumenti za skriptu. Kao rezultat, instalacija izgleda ovako:

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

Nakon toga, provjerimo da li je sve počelo:

$ 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

Međutim, prije ili kasnije sve će početi autorizacija neće raditi odmah! Činjenica je da je u korištenoj slici (situacija na drugim slikama je slična) proces hvatanja preusmjeravanja u povratnom pozivu implementiran pogrešno. Ova okolnost dovodi do toga da oauth briše kolačić koji nam sam oauth pruža...

Problem se rješava izgradnjom vlastite oauth slike sa zakrpom.

Zakrpite oauth i ponovo instalirajte

Da bismo to učinili, koristit ćemo sljedeći 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" ]

A evo kako izgleda sama zakrpa 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 "... 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

Sada možete napraviti sliku i gurnuti je u naš GitLab. Sljedeći u manifests/kube-dashboard-oauth2-proxy.yaml označite upotrebu željene slike (zamijenite je svojom):

 image: docker.io/colemickens/oauth2_proxy:latest

Ako imate registar koji je zatvoren autorizacijom, ne zaboravite dodati korištenje tajne za povlačenje slika:

      imagePullSecrets:
     - name: gitlab-registry

... i dodajte samu tajnu za registar:

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

Pažljivi čitalac će vidjeti da je dugi niz iznad base64 iz konfiguracije:

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

Ovo su korisnički podaci u GitLabu, Kubernetes kod će povući sliku iz registra.

Nakon što je sve urađeno, možete ukloniti trenutnu (ne radi ispravno) instalaciju Dashboard-a naredbom:

$ ./ctl.sh -d

... i ponovo instalirajte sve:

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

Vrijeme je da odete na Dashboard i pronađete prilično arhaično dugme za prijavu:

Nakon što kliknemo na njega, GitLab će nas pozdraviti i ponuditi da se prijavimo na svoju uobičajenu stranicu (naravno, ako se prethodno nismo prijavili na nju):

Prijavljujemo se sa GitLab akreditivima - i sve je gotovo:

O funkcijama kontrolne table

Ako ste programer koji ranije nije radio sa Kubernetes-om ili jednostavno iz nekog razloga niste ranije naišli na Dashboard, ilustrovaću neke od njegovih mogućnosti.

Prvo, možete vidjeti da je "sve zeleno":

Detaljniji podaci su također dostupni za podove, kao što su varijable okruženja, preuzeta slika, argumenti pokretanja i njihovo stanje:

Raspoređivanja imaju vidljive statuse:

...i ostali detalji:

... a tu je i mogućnost skaliranja implementacije:

Rezultat ove operacije:

Među ostalim korisnim funkcijama koje su već spomenute na početku članka je pregled dnevnika:

... i funkcija za prijavu na konzolu kontejnera odabranog pod:

Na primjer, možete pogledati i ograničenja/zahtjeve na čvorovima:

Naravno, ovo nisu sve mogućnosti panela, ali nadam se da ste dobili opštu ideju.

Nedostaci integracije i Dashboard

U opisanoj integraciji nema kontrole pristupa. Uz to, svi korisnici sa bilo kojim pristupom GitLabu dobijaju pristup Dashboard-u. Imaju isti pristup u samoj Dashboard-u, što odgovara pravima same Dashboard-a, koji definisani su u RBAC-u. Očigledno, ovo nije pogodno za svakoga, ali za naš slučaj se pokazalo dovoljnim.

Među uočljivim nedostacima na samoj kontrolnoj tabli, ističem sljedeće:

• nemoguće je ući u konzolu init kontejnera;
• nemoguće je uređivati ​​Deployments i StatefulSets, iako se to može popraviti u ClusterRole;
• Kompatibilnost Dashboarda sa najnovijim verzijama Kubernetesa i budućnost projekta postavljaju pitanja.

Posljednji problem zaslužuje posebnu pažnju.

Status kontrolne table i alternative

Tabela kompatibilnosti kontrolne ploče s Kubernetes izdanjima, predstavljena u najnovijoj verziji projekta (v1.10.1), nije baš zadovoljan:

Uprkos tome, postoji (već usvojen u januaru) PR #3476, koji najavljuje podršku za K8s 1.13. Osim toga, među problemima projekta možete pronaći reference na korisnike koji rade sa panelom u K8s 1.14. konačno, obavezuje u bazu koda projekta ne zaustavljajte se. Dakle (barem!) stvarni status projekta nije tako loš kao što se na prvi pogled može činiti iz službene tablice kompatibilnosti.

Konačno, postoje alternative za Dashboard. Među njima:

1. K8Dash — mlad interfejs (prvi urezivanje datiraju iz marta ove godine), koji već nudi dobre karakteristike, poput vizuelnog prikaza trenutnog statusa klastera i upravljanja njegovim objektima. Pozicioniran kao „interfejs u realnom vremenu“, jer automatski ažurira prikazane podatke bez potrebe za osvježavanjem stranice u pretraživaču.
2. Konzola OpenShift - web sučelje iz Red Hat OpenShift-a, koji će, međutim, u vaš klaster donijeti druge razvoje projekta, što nije pogodno za svakoga.
3. Kubernator je zanimljiv projekat, kreiran kao interfejs nižeg nivoa (od Dashboard) sa mogućnošću pregleda svih objekata klastera. Međutim, čini se da je njegov razvoj stao.
4. polaris - baš pre neki dan najavljeno projekat koji kombinuje funkcije panela (pokazuje trenutno stanje klastera, ali ne upravlja njegovim objektima) i automatsku „validaciju najboljih praksi“ (proverava ispravnost konfiguracija Deployments-a u klasteru).

Umesto zaključaka

Dashboard je standardni alat za Kubernetes klastere koje opslužujemo. Njegova integracija sa GitLabom takođe je postala deo naše podrazumevane instalacije, jer su mnogi programeri uzbuđeni zbog mogućnosti koje imaju sa ovim panelom.

Kubernetes Dashboard povremeno ima alternative iz zajednice otvorenog koda (i rado ćemo ih razmotriti), ali u ovoj fazi ostajemo pri ovom rješenju.

PS

Pročitajte i na našem blogu:

• «kubebox i druge ljuske za Kubernetes»;
• «Najbolje CI/CD prakse s Kubernetesom i GitLabom (pregled i video izvještaj)»;
• «Izgradite i implementirajte aplikacije u Kubernetesu koristeći dapp i GitLab CI»;
• «GitLab CI za kontinuiranu integraciju i isporuku u proizvodnji. Dio 1: naš cjevovod".

izvor: www.habr.com