Integrace Kubernetes Dashboard a uživatelů GitLab

Kubernetes Dashboard — snadný nástroj pro získání aktuálních informací o běžícím clusteru a jeho minimální správu. Oceníte ho ještě více, když je potřeba přístup k těmto funkcím nejen administrátorům/DevOps inženýrům, ale také těm, kteří nejsou tak zvyklí na konzoli a/nebo nemají v úmyslu se zabývat všemi nuancemi interakce s kubectl a dalšími nástroji. To se stalo i nám: vývojářům se zalíbilo rychlé připojení k webovému rozhraní Kubernetes, a protože používáme GitLab, integrace byla logickým krokem.

Proč to?

Samotní vývojáři mohou mít zájem o nástroj jako K8s Dashboard pro ladicí úkoly. Někdy je potřeba prohlížet logy a zdroje, a někdy i zabíjet pod, škálovat Deployments/StatefulSets a dokonce se připojit k konzolím kontejnerů (i takové žádosti se objevují, pro jejichž řešení však existuje jiná cesta — například přes kubectl-debug).

Kromě toho existuje i psychologický aspekt pro vedoucí pracovníky, když si chtějí prohlédnout cluster — vidět, že „všechno je zelené“, a tím se uklidnit, že „všechno funguje“ (což je samozřejmě velmi relativní… ale to už přesahuje rámec článku).

Jako standardní CI systém používáme se používá GitLab: ten používají všichni vývojáři. Proto bylo logické provést integraci Dashboardu s účty v GitLab.

Také bych chtěl poznamenat, že používáme NGINX Ingress. Pokud pracujete s jinými ingress řešeními, budete si muset sami najít analogy anotací pro autorizaci.

Zkoušíme integraci

Instalace Dashboardu

Pozor: Pokud plánujete opakovat níže popsané kroky, nejprve si přečtěte až k následující podkapitole, abyste se vyhnuli zbytečným operacím.

Jelikož tuto integraci používáme v mnoha instalacích, automatizovali jsme její instalaci. Zdroje potřebné pro to jsou zveřejněny v speciálním GitHub repozitáři. Jejich základem jsou mírně modifikované YAML konfigurace z oficiálního repozitáře Dashboardu, stejně jako Bash skript pro rychlé nasazení.

Skript instaluje Dashboard v clusteru a nastavuje ho na integraci s GitLab:

$ .\/ctl.sh  
Použití: ctl.sh [OPTION]... --gitlab-url GITLAB_URL --oauth2-id ID --oauth2-secret SECRET --dashboard-url DASHBOARD_URL
Nainstalujte kubernetes-dashboard do Kubernetes clusteru.
Povinné argumenty:
 -i, --install                nainstalovat do jména prostoru 'kube-system'
 -u, --upgrade                aktualizovat existující instalaci, použije heslo a názvy hostitelů
 -d, --delete                 odstranit vše, včetně jména prostoru
     --gitlab-url             nastavte gitlab url se schématem (https://gitlab.example.com)
     --oauth2-id              nastavte OAUTH2_PROXY_CLIENT_ID z gitlabu
     --oauth2-secret          nastavte OAUTH2_PROXY_CLIENT_SECRET z gitlabu
     --dashboard-url          nastavte dashboard url bez schématu (dashboard.example.com)
Nepovinné argumenty:
 -h, --help                   zobrazit tuto zprávu

Před jeho použitím je však nutné přihlásit se do GitLab: Administrace → Aplikace — a přidat novou aplikaci pro budoucí panel. Nazveme ji „kubernetes dashboard“:

V důsledku jejího přidání GitLab poskytne hash:

Tyto hash se používají jako argumenty pro skript. V důsledku toho vypadá instalace následovně:

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

Poté zkontrolujeme, že vše běží:

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

Dříve či později se vše spustí, ale okamžitá autorizace nebude fungovat! Je to tím, že v použitém obraze (situace u jiných obrazů je podobná) je nesprávně implementován proces zachytávání přesměrování v callbacku. Tato skutečnost vede k tomu, že oauth maže cookie, kterou nám (oauth) sám poskytuje…

Problém lze vyřešit sestavením vlastního oauth obrazu se záplatou.

Záplata k oauth a opětovná instalace

K tomu použijeme následující 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 [ \

A tak vypadá samotná záplata 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 "... probíhají testy"
-. /test.sh
+#. /test.sh
 
-for os in windows linux darwin; do
-    echo "... vytvářím v$version pro $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ářím v$version pro $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

Nyní můžeme zkompilovat obraz a "push" ho do našeho GitLab. Dále v manifests/kube-dashboard-oauth2-proxy.yaml určíme použití požadovaného obrazu (nahraďte ho vaším):

 image: docker.io/colemickens/oauth2_proxy:latest

Pokud máte registry chráněnou autorizací — nezapomeňte přidat použití tajemství pro pull obrazů:

      imagePullSecrets:
     - name: gitlab-registry

… a přidejte samo tajemství pro registry:

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

Pozorný čtenář si všimne, že výše uvedený dlouhý řetězec — je base64 configu:

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

Jsou to údaje uživatele v GitLab, které Kubernetes použije pro pull obrazu z registry.

Jakmile je vše hotovo, můžete odstranit současnou (nefunkční) instalaci Dashboard příkazem:

$ ./ctl.sh -d

… a nainstalovat vše znovu:

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

Nastal čas se přihlásit do Dashboardu a najít docela archaické tlačítko pro autorizaci:

Po jeho stisknutí se setkáme s GitLabem, který nabízí přihlásit se na své obvyklé stránce (samozřejmě, pokud jsme tam nebyli předtím autorizováni):

Přihlašujeme se s údaji GitLab — a vše se podařilo:

O možnostech Dashboardu

Pokud jste vývojář, který ještě nepracoval s Kubernetes, nebo pokud jste se z nějakého důvodu ještě nesetkali s Dashboardem, představím některé jeho funkce.

Za prvé, můžete se podívat, že "všechno je zelené":

Pro pod'y jsou k dispozici i podrobnější údaje, jako jsou proměnné prostředí, stažený obraz, spouštěcí argumenty a jejich stav:

U deploymentů jsou viditelné statusy:

… a další podrobnosti:

… a také je možné škálovat deployment:

Výsledek této operace:

Mezi další užitečné funkce, již zmíněné na začátku článku, je prohlížení logů:

… a funkce přístupu do konzole kontejnerů vybraného pod'u:

Také například můžete zkontrolovat limity/požadavky na uzlech:

Samozřejmě, že to nejsou všechny možnosti panelu, ale doufám, že celkový obrázek se nám podařilo vytvořit.

Nevýhody integrace a Dashboardu

V popsané integraci není žádné omezení přístupu. S ní mají všichni uživatelé, kteří mají jakýkoli přístup k GitLab, přístup do Dashboardu. Přístup v samotném Dashboardu mají všichni stejný, odpovídající právům samotného Dashboardu, která jsou určena v RBAC. Je zřejmé, že to nebude vyhovovat všem, ale pro náš případ to bylo dostatečné.

Mezi významné nevýhody samotného panelu Dashboardu patří následující:

• nelze se dostat do konzole init-kontejneru;
• nelze upravovat Deployments a StatefulSets, i když to lze opravit v ClusterRole;
• kompatibilita Dashboardu s nejnovějšími verzemi Kubernetes a budoucnost projektu vyvolává otázky.

Poslední problém si zaslouží zvláštní pozornost.

Status a alternativy Dashboardu

Tabulka kompatibility Dashboardu s verzemi Kubernetes, uvedená v poslední verzi projektu (v1.10.1), příliš nepotěší:

I přes to existuje (již přijatý v lednu) PR #3476, který oznamuje podporu K8s 1.13. Navíc, mezi problémy projektu lze najít zmínky uživatelů, kteří pracují s panelem v K8s 1.14. Nakonec, commity do kódové základny projektu neustávají. Takže (minimálně!) aktuální status projektu není tak špatný, jak by se na první pohled mohlo zdát z oficiální tabulky kompatibility.

Nakonec, Dashboard má alternativy. Mezi nimi:

1. K8Dash — mladé rozhraní (první commity pocházejí z března tohoto roku), které již nabízí slušné možnosti, jako je vizuální zobrazení aktuálního stavu cloudu a správa jeho objektů. Je prezentováno jako „rozhraní v reálném čase“, protože automaticky aktualizuje zobrazovaná data, aniž by bylo třeba obnovit stránku v prohlížeči.
2. OpenShift Console — webové rozhraní od Red Hat OpenShift, které však přinese do vašeho cloudu i další vyvinuté funkce projektu, které ne všechny uživatelé ocení.
3. Kubernator — zajímavý projekt, vytvořený jako nižší úroveň (než Dashboard) rozhraní s možností prohlížení všech objektů cloudu. Nicméně to vypadá, že jeho vývoj byl zastaven.
4. Polaris — doslova před pár dny oznámený projekt, který spojuje funkce panelu (ukazuje aktuální stav cloudu, ale neřídí jeho objekty) a automatické „validace nejlepších praktik“ (kontroluje cloud na správnost konfigurací spuštěných v něm Deployments).

Nam místo výstupů

Dashboard — standardní nástroj pro clouby Kubernetes, které spravujeme. Jeho integrace s GitLabem se také stala součástí naší „instalace podle defaultu“, protože mnozí vývojáři se těší z možností, které jim toto rozhraní přináší.

Pro Kubernetes Dashboard se čas od času objevují alternativy od komunity Open Source (a rádi je zvážíme), nicméně v tuto chvíli zůstáváme u tohoto řešení.

P.S.

Přečtěte si také náš blog:

• «kubebox a další konzolové shellové aplikace pro Kubernetes»;
• «Nejlepší praxe CI/CD s Kubernetes a GitLab (přehled a video přednáška)»;
• «Sestavení a nasazení aplikací v Kubernetes pomocí dapp a GitLab CI»;
• «GitLab CI pro nepřetržitou integraci a dodávku do produkce. Část 1: náš pipeline».

Zdroj: habr.com