Integrácia Kubernetes Dashboard a používateľov GitLab

Kubernetes Dashboard — jednoduchý nástroj na získanie aktuálnych informácií o bežiacom klastéri a základné riadenie. Jeho hodnotu si začnete uvedomovať ešte viac, keď potrebujú prístup k týmto možnosťami nielen administrátori/DevOps inžinieri, ale aj tí, ktorí nie sú zvyknutí na konzolu a/nebo nemajú v úmysle sa zaoberať všetkými nuansami interakcie s kubectl a inými nástrojmi. Tak sa stalo aj u nás: vývojárom sa žiada rýchly prístup k webovému rozhraniu Kubernetes, a keďže používame GitLab, riešenie sa ponúkalo samo o sebe.

Prečo to?

Priami vývojári sa môžu zaujímať o nástroj ako K8s Dashboard pre úlohy ladenia. Niekedy je potrebné prezerať si logy a prostriedky, inokedy aj zabíjať pod’ y, škálovať Deployments/StatefulSets a dokonca vstupovať do konzol kontajnerov (stávajú sa aj také požiadavky, na ktoré, mimochodom, existuje iná cesta — napríklad cez kubectl-debug).

Okrem toho existuje aj psychologický aspekt pre manažérov, keď chcú vidieť klaster — vidieť, že "všetko je zelené", a tak upokojiť dušu, že "všetko funguje" (čo je samozrejme dosť relatívne… ale to už presahuje rámec článku).

Ako štandardný CI systém máme sa používa GitLab: používajú ho všetci vývojári. Preto bolo logické sprístupniť im prístup integráciou Dashboardu s účtami v GitLabe.

Tiež by som rád zdôraznil, že používame NGINX Ingress. Ak pracujete s inými ingress riešeniami, budete si musieť sami nájsť analógy pre anotácie týkajúce sa autorizácie.

Skúšame integráciu

Inštalácia Dashboardu

Pozor: Ak plánujete opakovať nižšie popísané kroky, najprv si — aby ste sa vyhli zbytočným operáciám — prečítajte až po nasledujúcu podkapitolu.

Keďže túto integráciu používame v mnohých inštaláciách, automatizovali sme jej inštaláciu. Zdroje, ktoré budú potrebné pre toto, sú zverejnené v špeciálnom GitHub repozitári. V ich základe — len mierne modifikované YAML konfigurácie z oficiálneho repozitára Dashboard, ako aj Bash skript na rýchle nasadenie.

Skript inštaluje Dashboard do klastru a nastavuje ho na integráciu s GitLabom:

$ ./ctl.sh  
Použitie: ctl.sh [OPTION]... --gitlab-url GITLAB_URL --oauth2-id ID --oauth2-secret SECRET --dashboard-url DASHBOARD_URL
Nainštalovať kubernetes-dashboard do Kubernetes klastru.
Povinné argumenty:
 -i, --install                nainštalovať do 'kube-system' namespace
 -u, --upgrade                aktualizovať existujúcu inštaláciu, opätovne použije heslo a názvy hostiteľov
 -d, --delete                 odstrániť všetko, vrátane namespace
     --gitlab-url             nastaviť gitlab url s schémou (https://gitlab.example.com)
     --oauth2-id              nastaviť OAUTH2_PROXY_CLIENT_ID z gitlab
     --oauth2-secret          nastaviť OAUTH2_PROXY_CLIENT_SECRET z gitlab
     --dashboard-url          nastaviť dashboard url bez schémy (dashboard.example.com)
Voliteľné argumenty:
 -h, --help                   vypísať túto správu

Avšak pred jeho použitím je potrebné ísť do GitLab: Admin area → Applications — a pridať novú aplikáciu pre budúcu panel. Nazvime ju „kubernetes dashboard“:

Výsledkom jeho pridaní GitLab poskytne hashe:

Tieto hash sa používajú ako argumenty pre skript. Výsledkom, inštalácia vyzerá nasledovne:

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

Potom skontrolujeme, či sa všetko spustilo:

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

Skoro alebo neskoro sa všetko spustí, avšak autentifikácia nebude fungovať hneď! Ide o to, že v použitom obraze (situácia v iných obrazoch je analógia) je nesprávne implementovaný proces zachytávania presmerovania do callbacku. Toto okolnosť vedie k tomu, že oauth vymaže cookie, ktorú nám sám (oauth) poskytuje…

Problém sa rieši zostavením vlastného obrazu oauth s patchom.

Patch k oauth a opätovná inštalácia

Na to použijeme nasledujúci 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 toto je, ako vyzerá samotný patch 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 "... spúšťajú sa testy"
-.\/test.sh
+#.\/test.sh
 
-for os in windows linux darwin; do
-    echo "... vytváram v$version pre $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 "... vytváram v$version pre $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

Teraz môžeme zostaviť obraz a ´push´ ho do nášho GitLab. Ďalej v manifests/kube-dashboard-oauth2-proxy.yaml určíme použitie požadovaného obrazu (nahraďte ho svojím):

 image: docker.io/colemickens/oauth2_proxy:latest

Ak máte registráciu chránenú autorizáciou — nezabudnite pridať použitie tajného kódu na ťahanie obrazov:

      imagePullSecrets:
     - name: gitlab-registry

… a pridajte samotný tajný kód pre registráciu:

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

Pozorný čitateľ si všimne, že uvedený dlhý riadok je base64 kódovaná konfigurácia:

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

Toto sú údaje používateľa v GitLab, ktorým Kubernetes získa obraz z registrácie.

Po tom, čo je všetko hotové, môžete odstrániť aktuálnu (nefunkčnú) inštaláciu Dashboard príkazom:

$ .\/ctl.sh -d

… a nainštalovať všetko znovu:

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

Nastal čas vstúpiť do Dashboardu a nájsť dosť archaické tlačidlo autorizácie:

Po kliknutí naň nás stretne GitLab, ponúkajúci sa na autorizáciu na svojej známej stránke (samozrejme, ak sme tam neboli predtým autorizovaní):

Prihlásime sa s údajmi z GitLab a všetko sa podarilo:

O možnostiach Dashboardu

Ak ste vývojár, ktorý predtým nepracoval s Kubernetes, alebo ste sa z nejakého dôvodu nikdy nestretli s Dashboard, ilustrujem niektoré jeho možnosti.

Po prvé, môžete vidieť, že "všetko je zelené":

Sú dostupné aj podrobnejšie údaje o padoch, ako sú premenné prostredia, stiahnutý obraz, argumenty spustenia a ich stav:

U nasadení sú viditeľné stavy:

… a ďalšie podrobnosti:

… a tiež je možné zväčšiť nasadenie:

Výsledok tejto operácie:

Medzi ďalšie užitočné funkcie, ktoré boli už spomenuté na začiatku článku, patrí sledovanie logov:

… a funkcia prihlásenia do konzoly kontajnerov vybraného padu:

Navyše, napríklad, je možné zobraziť aj limity/požiadavky na uzloch:

Samozrejme, to nie sú všetky možnosti panela, ale dúfam, že sa vytvoril celkový obraz.

Nevýhody integrácie a Dashboard

V opísanej integrácii neexistuje žiadne oddeľovanie prístupu. S ňou majú všetci používatelia, ktorí majú akýkoľvek prístup k GitLab, prístup do Dashboardu. Prístup v samotnom Dashboarde je pre nich rovnaký, zodpovedajúci právam samotného Dashboardu, ktoré sú určené v RBAC. Je zrejmé, že to nevyhovuje všetkým, ale pre našu situáciu to bolo dostatočné.

Z pozoruhodných nevýhod v samotnom panei Dashboard si všímam nasledujúce:

• nie je možné dostať sa do konzoly init-kontajnera;
• nie je možné upravovať nasadenia a StatefulSets, hoci to je možné opraviť v ClusterRole;
• kompatibilita Dashboardu s najnovšími verziami Kubernetes a budúcnosť projektu sú otázne.

Posledný problém si zaslúži osobitnú pozornosť.

Stav a alternatívy Dashboardu

Tabuľka kompatibility Dashboardu s verziami Kubernetes, uvedená v poslednej verzii projektu (v1.10.1), veľmi nepoteší:

Napriek tomu existuje (už prijatý v januári) PR #3476, ktorý oznamuje podporu K8s 1.13. Okrem toho, medzi problémami projektu možno nájsť zmienky používateľov pracujúcich s panelom v K8s 1.14. Nakoniec, komitmenty do kódovej základne projektu neprestávajú. Takže (aspoň!) skutočný stav projektu nie je taký zlý, ako sa môže na prvý pohľad zdať z oficiálnej tabuľky kompatibility.

Nakoniec, Dashboard má alternatívy. Medzi nimi:

1. K8Dash — mladé rozhranie (prvé commity sú datované v marci tohto roku), ktoré už ponúka slušné možnosti, ako je vizuálne zobrazenie aktuálneho stavu klastera a správa jeho objektov. Pozicionuje sa ako „rozhranie v reálnom čase“, pretože automaticky aktualizuje zobrazené údaje bez nutnosti obnovovania stránky v prehliadači.
2. OpenShift Console — webové rozhranie od Red Hat OpenShift, ktoré však prinesie do vášho klastera aj ďalšie výsledky projektu, čo nie všetkým vyhovuje.
3. Kubernator — zaujímavý projekt, vytvorený ako nízkoúrovňové (oproti Dashboardu) rozhranie s možnosťou prezerania všetkých objektov klastera. Avšak všetko vyzerá tak, že jeho vývoj sa zastavil.
4. Polaris — doslova pred pár dňami oznámený projekt, ktorý kombinuje funkcie panela (zobrazuje aktuálny stav klastera, ale neriadi jeho objekty) a automatickej „validácie najlepších praktík“ (kontroluje klaster na správnosť konfigurácií nasadených v ňom Deployments).

Namiesto záverov

Dashboard — štandardný nástroj pre klastre Kubernetes, ktoré obsluhujeme. Jeho integrácia s GitLab sa tiež stala súčasťou našej „predvolenej inštalácie“, keďže mnohí vývojári sú nadšení z možností, ktoré im tento panel poskytuje.

K Kubernetes Dashboardu sa občas objavujú alternatívy od Open Source komunity (a radi ich zvážime), avšak v tejto fáze zostávame s týmto riešením.

P.S.

Prečítajte si tiež na našom blogu:

• «kubebox a ďalšie konzolové rozhrania pre Kubernetes»;
• «Najlepšie praktiky CI/CD s Kubernetes a GitLab (prezentácia a video prednášky)»;
• «Súbor a nasadenie aplikácií v Kubernetes pomocou dapp a GitLab CI»;
• «GitLab CI pre nepretržitú integráciu a dodávku do produkcie. Časť 1: náš pipeline».

Zdroj: habr.com