Integracija Kubernetes nadzorne ploče i GitLab korisnika

Kubernetes Dashboard alat je jednostavan za korištenje za dobivanje ažuriranih informacija o vašem pokrenutom klasteru i upravljanje njime uz minimalan napor. Počinjete to još više cijeniti kada pristup ovim mogućnostima trebaju ne samo administratori/DevOps inženjeri, već i oni koji su manje navikli na konzolu i/ili se ne namjeravaju baviti svim zamršenostima interakcije s kubectl i ostale komunalije. To se dogodilo s nama: programeri su htjeli brzi pristup Kubernetes web sučelju, a budući da koristimo GitLab, rješenje je došlo prirodno.

Zašto je ovo?

Izravni programeri mogli bi biti zainteresirani za alat kao što je K8s Dashboard za zadatke otklanjanja pogrešaka. Ponekad želite vidjeti zapisnike i resurse, a ponekad uništiti podove, skalirati Deployments/StatefulSets, pa čak i otići na konzolu spremnika (postoje i zahtjevi za koje, međutim, postoji drugi način - na primjer, kroz kubectl-debug).

Osim toga, postoji psihološki moment za menadžere kada žele pogledati klaster - vidjeti da je "sve zeleno", i tako se uvjeriti da "sve radi" (što je, naravno, vrlo relativno... ali to je izvan okvira članka).

Kao standardni CI sustav imamo primijenjena GitLab: koriste ga i svi programeri. Stoga, kako bi im se omogućio pristup, bilo je logično integrirati nadzornu ploču s GitLab računima.

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

Pokušaj integracije

Ugradnja nadzorne ploče

Pažnja: Ako ćete ponoviti korake u nastavku, tada - kako biste izbjegli nepotrebne radnje - prvo pročitajte sljedeći podnaslov.

Budući da koristimo ovu integraciju u mnogim instalacijama, automatizirali smo njezinu instalaciju. Za to su potrebni izvori objavljeni u posebno GitHub repozitorij. Temelje se na blago modificiranim YAML konfiguracijama iz službeno spremište nadzorne ploče, kao i Bash skriptu za brzu implementaciju.

Skripta instalira nadzornu ploču u klaster i konfigurira je za integraciju s 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 korištenja potrebno je otići na GitLab: Administratorsko područje → Aplikacije - i dodati novu aplikaciju za budući panel. Nazovimo to "kubernetes nadzorna ploča":

Kao rezultat dodavanja, GitLab će dati hashove:

Oni su ti koji se koriste kao argumenti scenariju. Kao rezultat toga, 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 je li 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

Prije ili kasnije sve će ipak krenuti autorizacija neće raditi odmah! Činjenica je da je na korištenoj slici (situacija na drugim slikama je slična) proces hvatanja preusmjeravanja u povratnom pozivu implementiran netočno. Ova okolnost dovodi do činjenice da oauth briše kolačić koji nam sam oauth daje...

Problem se rješava izgradnjom vlastite oauth slike pomoću zakrpe.

Zakrpite oauth i ponovno instalirajte

Da bismo to učinili, koristit ćemo sljedeću Docker datoteku:

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 sam rd.patch 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 izraditi sliku i unijeti je u naš GitLab. Sljedeći u manifests/kube-dashboard-oauth2-proxy.yaml označite korištenje željene slike (zamijenite je svojom):

 image: docker.io/colemickens/oauth2_proxy:latest

Ako imate registar koji je zatvoren autorizacijom, ne zaboravite dodati upotrebu tajne za slike povlačenja:

      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 čitatelj ć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 gotovo, možete ukloniti trenutnu (koja ne radi ispravno) instalaciju Nadzorne ploče naredbom:

$ ./ctl.sh -d

... i ponovno sve instalirajte:

$ ./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 nadzornu ploču i pronađete prilično arhaičan gumb za prijavu:

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

Prijavljujemo se s GitLab vjerodajnicama - i sve je gotovo:

O značajkama nadzorne ploče

Ako ste programer koji prije nije radio s Kubernetesom ili se jednostavno iz nekog razloga niste prije susreli s Dashboardom, ilustrirat ću neke od njegovih mogućnosti.

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

Detaljniji podaci također su dostupni za mahune, kao što su varijable okoline, preuzeta slika, argumenti pokretanja i njihovo stanje:

Implementacije imaju vidljive statuse:

...i ostali detalji:

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

Rezultat ove operacije:

Među ostalim korisnim značajkama koje smo već spomenuli na početku članka je pregled zapisa:

... i funkciju za prijavu na konzolu spremnika odabranog modula:

Na primjer, također možete pogledati ograničenja/zahtjeve na čvorovima:

Naravno, ovo nisu sve mogućnosti panela, ali nadam se da ste stekli opću ideju.

Nedostaci integracije i nadzorne ploče

U opisanoj integraciji nema kontrola pristupa. S njim svi korisnici s bilo kojim pristupom GitLabu dobivaju pristup nadzornoj ploči. Imaju isti pristup u samoj nadzornoj ploči, što odgovara pravima same nadzorne ploče, koja definirani su u RBAC-u. Očito, ovo nije prikladno za svakoga, ali za naš slučaj se pokazalo dovoljnim.

Među uočljivim nedostacima same nadzorne ploče ističem sljedeće:

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

Posljednji problem zaslužuje posebnu pozornost.

Status nadzorne ploče i alternative

Tablica kompatibilnosti nadzorne ploče s Kubernetes izdanjima, predstavljena u posljednjoj verziji projekta (v1.10.1), nije baš sretan:

Unatoč tome, postoji (već usvojen u siječnju) PR #3476, koji najavljuje podršku za K8s 1.13. Osim toga, među projektnim problemima možete pronaći reference na korisnike koji rade s panelom u K8s 1.14. Konačno, obvezuje se u bazu koda projekta ne prestaju. 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 nadzornoj ploči. Među njima:

1. K8Crtica — mlado sučelje (prvi komiti datiraju iz ožujka ove godine), koje već nudi dobre značajke, poput vizualnog prikaza trenutnog statusa klastera i upravljanja njegovim objektima. Pozicioniran kao "sučelje u stvarnom vremenu", jer automatski ažurira prikazane podatke bez potrebe da osvježite stranicu u pregledniku.
2. Konzola OpenShift - web sučelje iz Red Hat OpenShift, koje će, međutim, donijeti druge razvoje projekta u vaš klaster, što nije prikladno za sve.
3. Kubernator je zanimljiv projekt, kreiran kao sučelje niže razine (od nadzorne ploče) s mogućnošću pregleda svih objekata klastera. No, čini se da je njegov razvoj stao.
4. Polaris - baš neki dan najavio projekt koji kombinira funkcije panela (pokazuje trenutačno stanje klastera, ali ne upravlja njegovim objektima) i automatsku „provjeru valjanosti najboljih praksi” (provjerava klaster radi ispravnosti konfiguracija implementacija koje se u njemu izvode).

Umjesto zaključaka

Nadzorna ploča je standardni alat za Kubernetes klastere koje poslužujemo. Njegova integracija s GitLabom također je postala dio naše zadane instalacije, budući da su mnogi programeri uzbuđeni zbog mogućnosti koje imaju s ovim panelom.

Kubernetes nadzorna ploča povremeno ima alternative iz zajednice otvorenog koda (i rado ih razmatramo), 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šće)»;
• «Izradite i implementirajte aplikacije u Kubernetesu koristeći dapp i GitLab CI»;
• «GitLab CI za kontinuiranu integraciju i isporuku u proizvodnji. 1. dio: naš cjevovod".

Izvor: www.habr.com