Integrace Kubernetes Dashboard a uživatelů GitLab

Kubernetes Dashboard je snadno použitelný nástroj pro získávání aktuálních informací o běžícím clusteru a jeho správu s minimálním úsilím. O to více si toho začnete vážit, když přístup k těmto schopnostem potřebují nejen správci/inženýři DevOps, ale také ti, kteří jsou méně zvyklí na konzoli a/nebo se nehodlají zabývat všemi složitostmi interakce s kubectl a ostatní komunální služby. Stalo se to u nás: vývojáři chtěli rychlý přístup k webovému rozhraní Kubernetes, a protože používáme GitLab, řešení přišlo přirozeně.

Proč je to?

Přímé vývojáře by mohl zajímat nástroj jako K8s Dashboard pro ladění úloh. Někdy si chcete prohlížet protokoly a zdroje a někdy zabíjet pody, škálovat Deployments/StatefulSets a dokonce přejít do kontejnerové konzole (existují i ​​požadavky, pro které však existuje jiný způsob – např. kubectl-debug).

Navíc je tu pro manažery psychologický moment, když se chtějí na shluk podívat – vidět, že „všechno je zelené“, a ujistit se tak, že „vše funguje“ (což je ovšem velmi relativní... ale to je nad rámec článku).

Jako standardní CI systém máme aplikováno GitLab: používají jej také všichni vývojáři. Proto, abychom jim poskytli přístup, bylo logické integrovat Dashboard s účty GitLab.

Také poznamenám, že používáme NGINX Ingress. Pokud pracujete s ostatními vnikací řešení, budete muset nezávisle najít analogy anotací pro autorizaci.

Pokus o integraci

Instalace palubní desky

Pozor: Pokud se chystáte zopakovat níže uvedené kroky, pak - abyste se vyhnuli zbytečným operacím - si nejprve přečtěte další podnadpis.

Protože tuto integraci používáme v mnoha instalacích, zautomatizovali jsme její instalaci. Zdroje potřebné k tomu jsou zveřejněny v speciální úložiště GitHub. Jsou založeny na mírně upravených konfiguracích YAML z oficiální úložiště Dashboard, stejně jako Bash skript pro rychlé nasazení.

Skript nainstaluje Dashboard do clusteru a nakonfiguruje jej pro integraci 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

Před použitím však musíte přejít do GitLabu: Admin area → Applications – a přidat novou aplikaci pro budoucí panel. Říkejme tomu „panel kubernetes“:

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

Jsou to ty, které se používají jako argumenty skriptu. V důsledku toho instalace vypadá takto:

$ ./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 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

Dříve nebo později však vše začne autorizace nebude fungovat okamžitě! Faktem je, že v použitém obrázku (u ostatních obrázků je situace podobná) je proces zachycení přesměrování ve zpětném volání implementován nesprávně. Tato okolnost vede k tomu, že oauth vymaže soubor cookie, který nám poskytuje samotný oauth...

Problém je vyřešen vytvořením vlastního oauth obrazu s patchem.

Opravte oauth a znovu nainstalujte

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 [ "/bin/oauth2_proxy" ]
CMD [ "--upstream=http://0.0.0.0:8080/", "--http-address=0.0.0.0:4180" ]

A takto vypadá 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 "... 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

Nyní můžete vytvořit obrázek a vložit jej do našeho GitLabu. Další v manifests/kube-dashboard-oauth2-proxy.yaml uveďte použití požadovaného obrázku (nahraďte jej vlastním):

 image: docker.io/colemickens/oauth2_proxy:latest

Pokud máte registr, který je uzavřený autorizací, nezapomeňte přidat použití tajného klíče pro stahování obrázků:

      imagePullSecrets:
     - name: gitlab-registry

... a přidejte samotné tajemství pro registr:

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

Pozorný čtenář uvidí, že dlouhý řetězec výše je base64 z konfigurace:

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

Toto jsou uživatelská data v GitLabu, kód Kubernetes vytáhne obrázek z registru.

Poté, co je vše hotovo, můžete odstranit aktuální (nefungující správně) instalaci Dashboard příkazem:

$ ./ctl.sh -d

...a nainstalujte vše znovu:

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

Je čas přejít na Dashboard a najít poměrně archaické přihlašovací tlačítko:

Po kliknutí na něj nás GitLab přivítá s nabídkou přihlášení na svou obvyklou stránku (samozřejmě, pokud jsme se tam dříve nepřihlásili):

Přihlásíme se pomocí přihlašovacích údajů GitLab – a vše je hotovo:

O funkcích řídicího panelu

Pokud jste vývojář, který s Kubernetes ještě nepracoval, nebo se prostě z nějakého důvodu s Dashboardem ještě nesetkal, ukážu vám některé jeho možnosti.

Za prvé, můžete vidět, že „všechno je zelené“:

Pro moduly jsou k dispozici také podrobnější data, jako jsou proměnné prostředí, stažený obrázek, argumenty spuštění a jejich stav:

Nasazení mají viditelné stavy:

...a další podrobnosti:

... a je zde také možnost škálovat nasazení:

Výsledek této operace:

Mezi další užitečné funkce, které již byly zmíněny na začátku článku, patří prohlížení protokolů:

... a funkce pro přihlášení do kontejnerové konzole vybraného podu:

Můžete se například také podívat na limity/požadavky na uzlech:

To samozřejmě nejsou všechny možnosti panelu, ale doufám, že získáte obecnou představu.

Nevýhody integrace a Dashboardu

V popisované integraci není Řízení přístupu. Díky němu získají všichni uživatelé s jakýmkoli přístupem do GitLab přístup k Dashboardu. V samotném Dashboardu mají stejný přístup, odpovídající právům samotného Dashboardu, který jsou definovány v RBAC. Je zřejmé, že to není vhodné pro každého, ale pro náš případ se to ukázalo jako dostatečné.

Mezi znatelné nevýhody v samotném Dashboardu zaznamenávám následující:

• není možné se dostat do konzoly init kontejneru;
• není možné 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.

Stav řídicího panelu a alternativy

Tabulka kompatibility řídicího panelu s vydáními Kubernetes, prezentovaná v nejnovější verzi projektu (v1.10.1), ne moc šťastný:

Navzdory tomu existuje (již přijato v lednu) PR # 3476, která oznamuje podporu pro K8s 1.13. Kromě toho mezi problémy projektu můžete najít odkazy na uživatele pracující s panelem v K8s 1.14. Konečně, zavazuje do základny kódu projektu nepřestávejte. Skutečný stav projektu tedy (alespoň!) není tak špatný, jak by se na první pohled mohlo zdát z oficiální tabulky kompatibility.

Konečně existují alternativy k Dashboardu. Mezi nimi:

1. K8Dash — mladé rozhraní (první commity pocházejí z března tohoto roku), které již nabízí dobré funkce, jako je vizuální znázornění aktuálního stavu clusteru a správa jeho objektů. Umístěno jako „rozhraní v reálném čase“, protože automaticky aktualizuje zobrazená data, aniž byste museli aktualizovat stránku v prohlížeči.
2. Konzole OpenShift - webové rozhraní od Red Hat OpenShift, které však do vašeho clusteru přinese další vývoj projektu, který není vhodný pro každého.
3. Kubernator je zajímavý projekt, vytvořený jako rozhraní nižší úrovně (než Dashboard) s možností zobrazení všech objektů clusteru. Zdá se však, že se jeho vývoj zastavil.
4. Polaris - jen druhý den oznámil projekt, který kombinuje funkce panelu (zobrazuje aktuální stav clusteru, ale nespravuje jeho objekty) a automatické „validace best practices“ (kontroluje cluster na správnost konfigurací Deployments v něm běžících).

Namísto závěrů

Dashboard je standardní nástroj pro clustery Kubernetes, které obsluhujeme. Jeho integrace s GitLab se také stala součástí naší výchozí instalace, protože mnoho vývojářů je nadšeno z možností, které tento panel nabízí.

Kubernetes Dashboard má pravidelně alternativy z komunity Open Source (a my je rádi zvažujeme), ale v této fázi zůstáváme u tohoto řešení.

PS

Přečtěte si také na našem blogu:

• «kubebox a další shelly pro Kubernetes";
• «Nejlepší postupy CI/CD s Kubernetes a GitLab (recenze a video zpráva)";
• «Vytvářejte a nasazujte aplikace v Kubernetes pomocí dapp a GitLab CI";
• «GitLab CI pro nepřetržitou integraci a poskytování ve výrobě. Část 1: naše potrubí".

Zdroj: www.habr.com