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

Kubernetes Dashboard je ľahko použiteľný nástroj na získanie aktuálnych informácií o spustenom klastri a jeho minimálnej správe. Začnete si to vážiť ešte viac, keď prístup k týmto schopnostiam potrebujú nielen administrátori/devOps inžinieri, ale aj tí, ktorí sú menej zvyknutí na konzolu a/alebo nemajú v úmysle zaoberať sa všetkými zložitosťami interakcie s kubectl a ostatné komunálne služby. Stalo sa to u nás: vývojári chceli rýchly prístup k webovému rozhraniu Kubernetes a keďže používame GitLab, riešenie prišlo prirodzene.

Prečo je toto?

Priamych vývojárov môže zaujímať nástroj ako K8s Dashboard na ladenie úloh. Niekedy si chcete prezerať protokoly a zdroje a niekedy zabíjať pody, škálovať Deployments/StatefulSets a dokonca prejsť do kontajnerovej konzoly (sú aj požiadavky, na ktoré však existuje iný spôsob – napr. kubectl-debug).

Navyše je tu pre manažérov psychologický moment, keď sa chcú pozrieť na klaster – vidieť, že „všetko je zelené“, a tak sa uistiť, že „všetko funguje“ (čo je, samozrejme, veľmi relatívne... ale to je nad rámec článku).

Ako štandardný CI systém máme platiť GitLab: používajú ho aj všetci vývojári. Preto, aby sme im poskytli prístup, bolo logické integrovať Dashboard s účtami GitLab.

Poznamenám tiež, že používame NGINX Ingress. Ak spolupracujete s ostatnými vstupné riešenia, budete musieť nezávisle nájsť analógy anotácií na autorizáciu.

Pokus o integráciu

Inštalácia palubnej dosky

Pozor: Ak sa chystáte zopakovať nižšie uvedené kroky, potom - aby ste sa vyhli zbytočným operáciám - si najskôr prečítajte nasledujúci podnadpis.

Keďže túto integráciu používame v mnohých inštaláciách, zautomatizovali sme jej inštaláciu. Zdroje potrebné na to sú zverejnené v špeciálne úložisko GitHub. Sú založené na mierne upravených konfiguráciách YAML z oficiálne úložisko Dashboardu, ako aj Bash skript pre rýchle nasadenie.

Skript nainštaluje Dashboard do klastra a nakonfiguruje ho na integráciu s 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 použitím však musíte prejsť do GitLabu: oblasť Správca → Aplikácie - a pridať novú aplikáciu pre budúci panel. Nazvime to „kubernetes dashboard“:

V dôsledku jeho pridania GitLab poskytne hash:

Sú to tie, ktoré sa používajú ako argumenty skriptu. V dôsledku toho inštalácia vyzerá takto:

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

Potom skontrolujte, či sa všetko začalo:

$ 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

Skôr či neskôr sa však všetko začne autorizácia nebude fungovať okamžite! Faktom je, že v použitom obrázku (situácia v iných obrázkoch je podobná) je proces zachytenia presmerovania v spätnom volaní implementovaný nesprávne. Táto okolnosť vedie k tomu, že oauth vymaže súbor cookie, ktorý nám poskytuje samotný Oauth...

Problém je vyriešený vytvorením vlastného oauth obrazu s patchom.

Opravte autentizáciu a preinštalujte

Na tento účel 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 takto vyzerá samotná oprava 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

Teraz môžete vytvoriť obrázok a vložiť ho do nášho GitLabu. Ďalší v manifests/kube-dashboard-oauth2-proxy.yaml uveďte použitie požadovaného obrázka (nahraďte ho vlastným):

 image: docker.io/colemickens/oauth2_proxy:latest

Ak máte register uzavretý autorizáciou, nezabudnite pridať použitie tajného kľúča pre obrázky na stiahnutie:

      imagePullSecrets:
     - name: gitlab-registry

... a pridajte samotné tajomstvo pre register:

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

Pozorný čitateľ uvidí, že dlhý reťazec vyššie je base64 z konfigurácie:

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

Toto sú používateľské údaje v GitLab, kód Kubernetes vytiahne obrázok z registra.

Keď je všetko hotové, môžete odstrániť aktuálnu (nefungujúcu správne) inštaláciu Dashboardu príkazom:

$ ./ctl.sh -d

...a znova všetko nainštalujte:

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

Je čas prejsť na Dashboard a nájsť pomerne archaické prihlasovacie tlačidlo:

Po kliknutí naň nás GitLab privíta a ponúkne prihlásenie na svoju obvyklú stránku (samozrejme, ak sme sa tam predtým neprihlásili):

Prihlásime sa pomocou poverení GitLab – a všetko je hotové:

O funkciách informačného panela

Ak ste vývojár, ktorý s Kubernetes ešte nepracoval, alebo ste sa jednoducho z nejakého dôvodu ešte nestretli s Dashboardom, ukážem vám niektoré jeho možnosti.

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

Pre moduly sú k dispozícii aj podrobnejšie údaje, ako sú premenné prostredia, stiahnutý obrázok, argumenty spustenia a ich stav:

Nasadenia majú viditeľné stavy:

...a ďalšie podrobnosti:

... a je tu tiež možnosť škálovať nasadenie:

Výsledok tejto operácie:

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

... a funkcia na prihlásenie do kontajnerovej konzoly vybranej pod:

Môžete sa napríklad pozrieť aj na limity/požiadavky na uzly:

Samozrejme, toto nie sú všetky možnosti panela, ale dúfam, že získate všeobecnú predstavu.

Nevýhody integrácie a Dashboardu

V opísanej integrácii nie je Riadenie prístupu. Vďaka tomu získajú všetci používatelia s akýmkoľvek prístupom k GitLab prístup k Dashboardu. V samotnom Dashboarde majú rovnaký prístup, zodpovedajúci právam samotného Dashboardu, ktorý sú definované v RBAC. Je zrejmé, že to nie je vhodné pre každého, ale pre náš prípad sa to ukázalo ako dostatočné.

Medzi viditeľné nevýhody v samotnom Dashboarde uvádzam nasledovné:

• nie je možné dostať sa do konzoly iniciačného kontajnera;
• nie je možné upravovať Deployments a StatefulSets, hoci to možno opraviť v ClusterRole;
• Kompatibilita Dashboardu s najnovšími verziami Kubernetes a budúcnosť projektu vyvolávajú otázky.

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

Stav palubnej dosky a alternatívy

Tabuľka kompatibility dashboardu s vydaniami Kubernetes prezentovaná v najnovšej verzii projektu (v1.10.1), nie veľmi šťastný:

Napriek tomu existuje (prijatý už v januári) PR #3476, ktorá oznamuje podporu pre K8s 1.13. Okrem toho medzi problémami projektu môžete nájsť odkazy na používateľov pracujúcich s panelom v K8s 1.14. nakoniec zaväzuje do základne kódu projektu neprestávajte. Skutočný stav projektu teda (aspoň!) nie je taký zlý, ako by sa na prvý pohľad mohlo zdať z oficiálnej tabuľky kompatibility.

Nakoniec existujú alternatívy k Dashboardu. Medzi nimi:

1. K8Dash — mladé rozhranie (prvé záväzky pochádzajú z marca tohto roku), ktoré už ponúka dobré funkcie, ako napríklad vizuálnu reprezentáciu aktuálneho stavu klastra a správu jeho objektov. Umiestnené ako „rozhranie v reálnom čase“, pretože automaticky aktualizuje zobrazené údaje bez toho, aby ste museli obnoviť stránku v prehliadači.
2. Konzola OpenShift - webové rozhranie od Red Hat OpenShift, ktoré však do vášho klastra prinesie ďalší vývoj projektu, ktorý nie je vhodný pre každého.
3. Kubernator je zaujímavý projekt, vytvorený ako rozhranie nižšej úrovne (ako Dashboard) s možnosťou zobrazenia všetkých objektov klastra. Zdá sa však, že jeho vývoj sa zastavil.
4. Polaris - len druhý deň oznámil projekt, ktorý kombinuje funkcie panela (zobrazuje aktuálny stav klastra, ale nespravuje jeho objekty) a automatickú „validáciu najlepších postupov“ (kontroluje klaster na správnosť konfigurácií Nasadení, ktoré v ňom bežia).

Namiesto záverov

Dashboard je štandardný nástroj pre klastre Kubernetes, ktoré poskytujeme. Jeho integrácia s GitLab sa tiež stala súčasťou našej predvolenej inštalácie, pretože mnohí vývojári sú nadšení z možností, ktoré tento panel ponúka.

Kubernetes Dashboard má pravidelne alternatívy z komunity Open Source (a my ich radi zvažujeme), ale v tejto fáze zostávame pri tomto riešení.

PS

Prečítajte si aj na našom blogu:

• «kubebox a ďalšie shelly pre Kubernetes»;
• «Najlepšie postupy CI/CD s Kubernetes a GitLab (recenzia a video správa)»;
• «Vytvárajte a nasadzujte aplikácie v Kubernetes pomocou dapp a GitLab CI»;
• «GitLab CI pre nepretržitú integráciu a poskytovanie vo výrobe. Časť 1: naše potrubie".

Zdroj: hab.com