Integracija nadzorne plošče Kubernetes in uporabnikov GitLab

Nadzorna plošča Kubernetes je orodje, ki je preprosto za uporabo, za pridobivanje najnovejših informacij o vaši delujoči gruči in njeno upravljanje z minimalnim naporom. Začneš še bolj ceniti, ko dostopa do teh zmožnosti ne potrebujejo samo skrbniki/inženirji DevOps, ampak tudi tisti, ki so manj navajeni na konzolo in/ali se ne nameravajo ukvarjati z vsemi zapletenostmi interakcije s kubectl in druge pripomočke. To se je zgodilo pri nas: razvijalci so želeli hiter dostop do spletnega vmesnika Kubernetes in ker uporabljamo GitLab, je rešitev prišla sama po sebi.

Zakaj je to?

Neposredne razvijalce bo morda zanimalo orodje, kot je K8s Dashboard, za naloge odpravljanja napak. Včasih si želite ogledati dnevnike in vire, včasih pa uničiti pode, prilagoditi razmestitve/StatefulSets in celo iti na konzolo vsebnika (obstajajo tudi zahteve, za katere pa obstaja drug način - na primer prek kubectl-debug).

Poleg tega obstaja psihološki moment za menedžerje, ko želijo pogledati grozd - videti, da je "vse zeleno", in se tako prepričati, da "vse deluje" (kar je seveda zelo relativno ... vendar to presega obseg članka).

Kot standardni sistem CI imamo velja GitLab: uporabljajo ga tudi vsi razvijalci. Da bi jim zagotovili dostop, je bilo zato logično integrirati nadzorno ploščo z računi GitLab.

Omenil bom tudi, da uporabljamo NGINX Ingress. Če delate z drugimi vhodne rešitve, boste morali samostojno poiskati analoge opomb za avtorizacijo.

Poskus integracije

Namestitev armaturne plošče

Pozornost: Če nameravate ponoviti spodnje korake, potem - da se izognete nepotrebnim operacijam - najprej preberite naslednji podnaslov.

Ker to integracijo uporabljamo v številnih namestitvah, smo njeno namestitev avtomatizirali. Za to potrebni viri so objavljeni v posebno GitHub repozitorij. Temeljijo na rahlo spremenjenih konfiguracijah YAML iz uradno skladišče nadzorne plošče, kot tudi skript Bash za hitro uvajanje.

Skript namesti nadzorno ploščo v gručo in jo konfigurira za integracijo z 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

Pred uporabo pa morate iti v GitLab: Skrbniško območje → Aplikacije - in dodati novo aplikacijo za prihodnjo ploščo. Recimo temu »nadzorna plošča kubernetes«:

Kot rezultat dodajanja bo GitLab zagotovil zgoščene vrednosti:

To so tisti, ki se uporabljajo kot argumenti skripta. Kot rezultat, namestitev izgleda takole:

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

Po tem preverimo, ali se je vse zač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

Prej ali slej pa se bo vse začelo avtorizacija ne bo delovala takoj! Dejstvo je, da je na uporabljeni sliki (situacija na drugih slikah je podobna) postopek lovljenja preusmeritve v povratni klic implementiran nepravilno. Ta okoliščina vodi do dejstva, da oauth izbriše piškotek, ki nam ga posreduje sam oauth ...

Težavo rešite tako, da s popravkom zgradite lastno sliko oauth.

Popravite oauth in znova namestite

Za to bomo uporabili naslednjo datoteko Docker:

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" ]

In tukaj je videti sam popravek 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

Zdaj lahko sestavite sliko in jo potisnete v naš GitLab. Naslednji v manifests/kube-dashboard-oauth2-proxy.yaml navedite uporabo želene slike (zamenjajte jo s svojo):

 image: docker.io/colemickens/oauth2_proxy:latest

Če imate register, ki je zaprt z avtorizacijo, ne pozabite dodati uporabe skrivnosti za vlečne slike:

      imagePullSecrets:
     - name: gitlab-registry

... in dodajte samo skrivnost za register:

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

Pozoren bralec bo videl, da je dolgi niz zgoraj base64 iz konfiguracije:

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

To so uporabniški podatki v GitLabu, koda Kubernetes bo potegnila sliko iz registra.

Ko je vse opravljeno, lahko odstranite trenutno (nedelujočo) namestitev nadzorne plošče z ukazom:

$ ./ctl.sh -d

... in znova namestite vse:

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

Čas je, da greste na nadzorno ploščo in najdete precej arhaičen gumb za prijavo:

Po kliku nanjo nas GitLab pozdravi in ​​ponudi prijavo na svojo običajno stran (seveda, če se tam predhodno nismo prijavili):

Prijavimo se s poverilnicami GitLab - in vse je narejeno:

O funkcijah nadzorne plošče

Če ste razvijalec, ki še niste delali s Kubernetesom ali preprosto iz nekega razloga še niste naleteli na nadzorno ploščo, bom ponazoril nekaj njenih zmogljivosti.

Najprej lahko vidite, da je "vse zeleno":

Za sklope so na voljo tudi podrobnejši podatki, kot so spremenljivke okolja, prenesena slika, argumenti za zagon in njihovo stanje:

Razmestitve imajo vidna stanja:

...in ostale podrobnosti:

... obstaja pa tudi zmožnost povečanja uvajanja:

Rezultat te operacije:

Med drugimi uporabnimi funkcijami, ki smo jih že omenili na začetku članka, je ogled dnevnikov:

... in funkcijo za prijavo v konzolo vsebnika izbranega sklopa:

Ogledate si lahko na primer tudi omejitve/zahteve na vozliščih:

Seveda to niso vse zmožnosti plošče, vendar upam, da ste dobili splošno predstavo.

Slabosti integracije in nadzorne plošče

V opisani integraciji ni nadzor dostopa. Z njo vsi uporabniki s kakršnimkoli dostopom do GitLaba pridobijo dostop do nadzorne plošče. Imajo enak dostop do same nadzorne plošče, kar ustreza pravicam same nadzorne plošče, ki so opredeljeni v RBAC. Seveda to ni primerno za vsakogar, vendar se je za naš primer izkazalo za dovolj.

Med opaznimi slabostmi same nadzorne plošče ugotavljam naslednje:

• nemogoče je priti v konzolo init vsebnika;
• nemogoče je urejati Deployments in StatefulSets, čeprav je to mogoče popraviti v ClusterRole;
• Združljivost nadzorne plošče z najnovejšimi različicami Kubernetesa in prihodnost projekta sprožata vprašanja.

Zadnji problem si zasluži posebno pozornost.

Stanje nadzorne plošče in možnosti

Tabela združljivosti nadzorne plošče z izdajami Kubernetes, predstavljena v najnovejši različici projekta (v1.10.1), ne preveč vesel:

Kljub temu obstaja (že sprejet januarja) PR # 3476, ki napoveduje podporo za K8s 1.13. Poleg tega lahko med projektnimi težavami najdete sklicevanja na uporabnike, ki delajo s ploščo v K8s 1.14. končno, se zaveže v bazo kode projekta ne ustavite. Torej (vsaj!) dejansko stanje projekta ni tako slabo, kot se na prvi pogled zdi iz uradne tabele združljivosti.

Končno obstajajo alternative nadzorni plošči. Med njimi:

1. K8Dash — mlad vmesnik (prvi commit-i segajo v marec letos), ki že ponuja dobre lastnosti, kot je vizualni prikaz trenutnega stanja gruče in upravljanje njenih objektov. Postavljen kot "vmesnik v realnem času", ker samodejno posodobi prikazane podatke, ne da bi morali osvežiti stran v brskalniku.
2. Konzola OpenShift - spletni vmesnik iz Red Hat OpenShift, ki pa bo v vašo gručo prinesel druge razvoje projekta, ki ni primeren za vsakogar.
3. Kubernator je zanimiv projekt, ustvarjen kot vmesnik na nižji ravni (od nadzorne plošče) z možnostjo ogleda vseh objektov gruče. Vendar se zdi, da se je njen razvoj ustavil.
4. Polaris - ravno drugi dan napovedal projekt, ki združuje funkcije plošče (prikazuje trenutno stanje gruče, vendar ne upravlja njenih objektov) in samodejno "preverjanje najboljših praks" (preverja gručo za pravilnost konfiguracij uvajanja, ki se izvajajo v njej).

Namesto zaključkov

Nadzorna plošča je standardno orodje za gruče Kubernetes, ki jim služimo. Njegova integracija z GitLabom je prav tako postala del naše privzete namestitve, saj je veliko razvijalcev navdušenih nad zmožnostmi, ki jih imajo s to ploščo.

Kubernetes Dashboard ima občasno alternative iz odprtokodne skupnosti (in z veseljem jih upoštevamo), vendar na tej stopnji ostajamo pri tej rešitvi.

PS

Preberite tudi na našem blogu:

• «kubebox in druge lupine za Kubernetes»;
• «Najboljše prakse CI/CD s Kubernetesom in GitLabom (pregled in video poročilo)»;
• «Zgradite in razmestite aplikacije v Kubernetesu z uporabo dapp in GitLab CI»;
• «GitLab CI za stalno integracijo in dostavo v proizvodnji. 1. del: naš plinovod".

Vir: www.habr.com