Integracija Kubernetes Dashborda i korisnika GitLaba

Kubernetes Dashboard — jednostavan alat za dobivanje ažuriranih informacija o aktivnom klasteru i minimalno upravljanje njime. Počinjete ga više cijeniti kada je pristup tim mogućnostima potreban ne samo administratorima ili DevOps inženjerima, već i onima koji su manje navikli na konzolu i/ili ne namjeravaju se zamarati svim nijansama interakcije s kubectl i drugim alatima. Tako je i kod nas: programerima je želio brz pristup web sučelju Kubernetes, a budući da koristimo GitLab, rješenje se samo nametnulo.

Zašto?

Neposredni programeri mogli bi biti zainteresirani za alat poput K8s Dashboard za zadatke vezane uz otklanjanje grešaka. Ponekad je potrebno pregledavati logove i resurse, a ponekad i ubijati podove, skalirati Deployments/StatefulSets i čak ulaziti u konzolu kontejnera (događaju se i takvi zahtjevi, za čije rješenje postoji i drugi put — na primjer, kroz kubectl-debug).

Osim toga, postoji i psihološki moment za vođe kada žele pogledati klaster — vidjeti da je 'sve zeleno' i na taj način se smiriti da 'sve radi' (što, naravno, vrlo relativno… ali to već izlazi iz okvira ovog članka).

Kao standardni CI sustav koristimo se koristi GitLab: njime se koriste svi programeri. Stoga, da bismo im pružili pristup, bilo je logično učiniti integraciju Dashboardsa s nalogom u GitLab-u.

Također napominjem da koristimo NGINX Ingress. Ako radite s drugim ingress rješenjima, morat ćete sami pronaći odgovarajuće analogije za autorizaciju.

Pokušavamo integraciju

Instalacija Dashboardsa

Pažnja: Ako planirate ponoviti opisane korake, onda — kako biste izbjegli suvišne operacije — prvo pročitajte do sljedeće podnaslov.

Budući da ovu integraciju koristimo u mnogo instalacija, automatizirali smo njezinu instalaciju. Izvori koji su potrebni za to objavljeni su u posebnom GitHub repozitoriju. Temelji se na neznatno modificiranim YAML konfiguracijama iz službenog repozitorija Dashboardsa, kao i Bash skriptu za brzu implementaciju.

Skripta instalira Dashboard u klaster i konfigurira ga za integraciju s GitLab-om:

$ .\/ctl.sh  
Usage: ctl.sh [OPTION]... --gitlab-url GITLAB_URL --oauth2-id ID --oauth2-secret SECRET --dashboard-url DASHBOARD_URL
Instalirajte kubernetes-dashboard na Kubernetes klaster.
Obavezni argumenti:
 -i, --install                instalira u 'kube-system' namespace
 -u, --upgrade                nadogradite postojeću instalaciju, ponovo će koristiti lozinku i imena hostova
 -d, --delete                 uklonite sve, uključujući namespace
     --gitlab-url             postavite gitlab url s shemom (https://gitlab.example.com)
     --oauth2-id              postavite OAUTH2_PROXY_CLIENT_ID iz gitlaba
     --oauth2-secret          postavite OAUTH2_PROXY_CLIENT_SECRET iz gitlaba
     --dashboard-url          postavite dashboard url bez sheme (dashboard.example.com)
Opcionalni argumenti:
 -h, --help                   ispiši ovu poruku

Međutim, prije nego što ga iskoristite, potrebno je da se prijavite u GitLab: Admin područje → Aplikacije — i dodajte novu aplikaciju za buduću ploču. Nazovimo je „kubernetes dashboard“:

Kao rezultat njegovog dodavanja, GitLab će pružiti heševe:

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 pokrenuto:

$ kubectl -n kube-system get pod | egrep '(dash|oauth)'
kubernetes-dashboard-76b55bc9f8-xpncp   1\/1       Radi   0          14s
oauth2-proxy-5586ccf95c-czp2v           1\/1       Radi   0          14s

prije ili kasnije sve će se pokrenuti, međutim autorizacija odmah neće raditi! Radi se o tome da je u korištenoj slici (situacija u drugim slikama je slična) neispravno implementiran proces hvatanja redirekcije u callback. Ova okolnost dovodi do toga da oauth briše kolačić koji sam (oauth) pruža…

Problem se rješava izradom vlastite slike oauth s ispravkom.

Ispravka za oauth i ponovna instalacija

Za to ćemo koristiti 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 ispravka 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 "... pokreću se testovi"
-.\/test.sh
+#.\/test.sh
 
-for os in windows linux darwin; do
-    echo "... gradimo v$version za $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 "... gradimo v$version za $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žemo napraviti gradnju slike i 'push' njen u naš GitLab. Sljedeće u manifests/kube-dashboard-oauth2-proxy.yaml navest ćemo upotrebu potrebne slike (zamijenite je svojom):

 image: docker.io/colemickens/oauth2_proxy:latest

Ako imate privatni registry za autorizaciju — nemojte zaboraviti dodati upotrebu tajne za pull slika:

      imagePullSecrets:
     - name: gitlab-registry

… i dodajte samu tajnu za registry:

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

Pažljivi čitatelj će primijetiti da je dugačka linija iznad — to base64 od konfiguracije:

{
 "registry.company.com": {
 "username": "oauth2",
 "password": "PASSWORD",
 "auth": "AUTH_TOKEN",
 "email": "mail@company.com"
}
}

Ovo su podaci korisnika u GitLabu, kod kojima će Kubernetes pull sliku iz registry.

Nakon što je sve obavljeno, možete ukloniti trenutnu (neispravnu) instalaciju Dashboarda naredbom:

$ .\/ctl.sh -d

… i reinstalirati sve:

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

Vrijeme je da se prijavite u Dashboard i pronađete prilično arhaičnu dugmad za autorizaciju:

Nakon što je pritisnemo, susretnut ćemo GitLab koji nudi da se prijavimo na svojoj poznatoj stranici (naravno, ako već nismo bili prijavljeni):

Prijavljujemo se s podacima GitLaba — i to je to:

O mogućnostima Dashboarda

Ako ste developer koji prije nije radio s Kubernetesom, ili jednostavno iz nekog razloga niste prije koristili Dashboard — ilustrirat ću neke od njegovih mogućnosti.

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

Za podove su dostupni i detaljniji podaci, poput varijabli okoliša, preuzetog slike, argumenata pokretanja, njihovog stanja:

Vidljivost statusa za deployment-e:

… i druge pojedinosti:

… kao i mogućnost skaliranja deployment-a:

Rezultat ove operacije:

Među ostalim korisnim mogućnostima, već spomenutim na početku članka, — gledanje logova:

… i funkcija ulaska u konzolu kontejnera odabranog poda:

Također, možete vidjeti i limite/zahtjeve na čvorovima:

Naravno, ovo nije sve mogućnosti panela, ali se nadam da je opća slika jasna.

Nedostaci integracije i Dashboard-a

U opisanom integraciji nema nikakvog ograničenja pristupa. Sa njom svi korisnici koji imaju bilo kakav pristup GitLabu dobijaju pristup Dashboard-u. Pristup u samom Dashboard-u im je isti, prema pravima samog Dashboard-a koja određuju RBAC. Očito, to neće odgovarati svima, ali u našem slučaju se pokazalo dovoljnim.

Među značajnim minusima u samom Dashboard-u istaknuo bih sljedeće:

• nije moguće ući u konzolu init-kontejnera;
• nije moguće uređivati Deployments i StatefulSets, iako se to može popraviti u ClusterRole;
• kompatibilnost Dashboard-a s najnovijim verzijama Kubernetesa i budućnost projekta izaziva pitanja.

Posljednji problem zaslužuje posebnu pažnju.

Status i alternative Dashboard-a

Tablica kompatibilnosti Dashboard-a s verzijama Kubernetesa, predstavljena u najnovijoj verziji projekta (v1.10.1), ne ulijeva povjerenje:

Unatoč tome, postoji (već prihvaćeno u siječnju) PR #3476, koji objavljuje podršku za K8s 1.13. Osim toga, među problematikama projekta mogu se naći spominjanja korisnika koji rade s panelom na K8s 1.14. Na kraju, commiti u kodnu bazu projekta ne prestaju. Tako da (barem!) stvarni status projekta nije toliko loš kao što se u početku može činiti iz službene tablice kompatibilnosti.

Na kraju, Dashboard ima alternative. Među njima:

1. K8Dash — mladenačko sučelje (prvi commitovi datiraju iz ožujka ove godine), već nudi dobre mogućnosti, kao što je vizualizacija trenutnog statusa klastera i upravljanje njegovim objektima. Pozicionira se kao "sučelje u stvarnom vremenu", jer automatski ažurira prikazane podatke, ne zahtijevajući osvježavanje stranice u pregledniku.
2. OpenShift Console — web sučelje od Red Hat OpenShift, koje će, međutim, donijeti u vaš klaster i druge karakteristike projekta, što ne odgovara svima.
3. Kubernator — zanimljiv projekt, kreiran kao niže razine (nego Dashboard) sučelje s mogućnošću pregledavanja svih objekata klastera. Međutim, sve izgleda kao da je razvoj prekinut.
4. Polaris — doslovno prije nekoliko dana najavljen projekt, koji kombinira funkcije ploče (prikazuje trenutačno stanje klastera, ali ne upravlja njegovim objektima) i automatske "validacije najboljih praksi" (provjerava klaster na ispravnost konfiguracija pokrenutih u njemu Deployments).

Umesto rezultata

Dashboard — standardni alat za klastere Kubernetes, koje podržavamo. Njegova integracija s GitLabom također je postala dio naše "zadane instalacije", budući da su mnogi programeri zadovoljni mogućnostima koje im ova ploča pruža.

U Kubernetes Dashboard s vremena na vrijeme pojavljuju se alternative iz Open Source zajednice (i rado ih razmatramo), no u ovom trenutku ostajemo s ovim rješenjem.

P.S.

Pročitajte i na našem blogu:

• «kubebox i drugi konzole za Kubernetes»;
• «Najbolje prakse CI/CD s Kubernetesom i GitLabom (pregled i video prezentacija)»;
• «Izgradnja i uvođenje aplikacija u Kubernetes s dapp i GitLab CI»;
• «GitLab CI za neprekidnu integraciju i isporuku u produkciju. Dio 1: naš pipeline».

Izvor: habr.com