🥇A Kubernetes Dashboard és GitLab felhasználók integrációja

A Kubernetes Dashboard — egy könnyen használható eszköz, amely lehetővé teszi a működő klaszterre vonatkozó aktuális információk beszerzését és minimális kezelését. Még jobban értékelni kezded, amikor nemcsak az adminisztrátoroknak / DevOps mérnököknek van szükségük ezekre a lehetőségekre, hanem azoknak is, akik kevésbé szoktak hozzá a konzolhoz és / vagy nem kívánják megismerni az összes részletet a kubectl és más segédprogramok használatával. Velünk is így történt: a fejlesztők gyors hozzáférést szerettek volna a Kubernetes webes felületéhez, és mivel GitLab-ot használunk, a megoldás magától jött.

Miért?

A közvetlen fejlesztők érdeklődhetnek egy olyan eszköz iránt, mint a K8s Dashboard, a hibakeresési feladatokhoz. Néha szívesen áttekintik a naplókat és az erőforrásokat, máskor pedig szeretnék megölni a podokat, skálázni a Deployments / StatefulSets-t, sőt akár bejelentkezni a konténerek konzoljába (ezek a kérések is előfordulnak, amelyek megoldására van másik lehetőség — például a kubectl-debug).

Ezen kívül van egy pszichológiai szempont is a vezetők számára, amikor szeretnék látni a klasztert — látni, hogy „minden zöld”, és így megnyugtatni magukat, hogy „minden működik” (ami persze elég relatív… de ez már a cikk keretein kívül esik).

Standard CI rendszerként nekünk használatban van a GitLab: ezt használják a fejlesztők is. Ezért ésszerű volt integrálni a Dashboard-ot a GitLab fiókokkal.

Megemlítem azt is, hogy NGINX Ingress-t használunk. Ha viszont más ingress megoldásokkal dolgozik,, akkor önállóan kell hasonló annotációkat keresnie az engedélyezéshez.

Próbáljuk az integrációt

A Dashboard telepítése

Figyelem: Ha követni kívánja az alábbi lépéseket, akkor — a felesleges műveletek elkerülése érdekében — először olvassa el a következő alcímet.

Mivel ezt az integrációt sok installációban használjuk, automatizáltuk a telepítését. Az ehhez szükséges forrásfájlok közzétéve vannak egy speciális GitHub tárolón. Ezek alapja kissé módosított YAML konfigurációk az hivatalos Dashboard tárolóból, valamint egy Bash script a gyors telepítéshez.

A script telepíti a Dashboard-ot a klaszterre és beállítja az integrációt a GitLab-lal:

$ .\/ctl.sh  
Usage: ctl.sh [OPTION]... --gitlab-url GITLAB_URL --oauth2-id ID --oauth2-secret SECRET --dashboard-url DASHBOARD_URL
Kubernetes-dashboard telepítése a Kubernetes klaszterbe.
Kötelező argumentumok:
 -i, --install                telepítés a 'kube-system' névtérbe
 -u, --upgrade                meglévő telepítés frissítése, újra felhasználja a jelszót és a gazda neveket
 -d, --delete                 mindent eltávolít, beleértve a névteret is
     --gitlab-url             gitlab URL beállítása sémával (https:\/\/gitlab.example.com)
     --oauth2-id              OAUTH2_PROXY_CLIENT_ID beállítása a gitlab-ból
     --oauth2-secret          OAUTH2_PROXY_CLIENT_SECRET beállítása a gitlab-ból
     --dashboard-url          dashboard URL beállítása séma nélkül (dashboard.example.com)
Opcionális argumentumok:
 -h, --help                   ezt az üzenetet jeleníti meg

Azonban a használata előtt be kell lépni a GitLab-ba: Admin terület → Alkalmazások — és egy új alkalmazást kell hozzáadni a jövőbeli panel számára. Hívjuk «kubernetes dashboard»-nak:

Az új alkalmazás hozzáadásával a GitLab hash-kódokat fog biztosítani:

Ezeket használjuk a szkript argumentumaiként. Így a telepítés a következőképpen néz ki:

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

Ezt követően ellenőrizzük, hogy minden elindult-e:

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

Előbb-utóbb minden elindul, azonban azonnal a hitelesítés nem fog működni! Az a helyzet, hogy a használt képben (más képek helyzete hasonló) helytelenül van megvalósítva a visszairányítás kezelése a callbacken. Ez a tény arra vezet, hogy az oauth törli a cookie-t, amit maga (oauth) ad nekünk...

A probléma megoldható a saját oauth képkészítésével javítással.

Patch az oauth-hoz és ismételt telepítés

Ehhez a következő Dockerfile-t fogjuk használni:

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

Így néz ki a 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 "... tesztek futtatása"
-.\/test.sh
+#.\/test.sh
 
-for os in windows linux darwin; do
-    echo "... v$version készítése $os/$arch számára"
-    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 "... v$version készítése $os/$arch számára"
+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

Most már elkészíthetjük a képet és feltölthetjük azt a saját GitLab-unkra. Ezután manifests/kube-dashboard-oauth2-proxy.yaml megadjuk a szükséges kép használatát (cseréld ki a sajátodra):

 image: docker.io/colemickens/oauth2_proxy:latest

Ha zárt hitelesítéssel rendelkező registry-d van, ne felejtsd el hozzáadni a titkot a képek lehúzásához:

      imagePullSecrets:
     - name: gitlab-registry

… és add hozzá magát a titkot a registry-hez:

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

A figyelmes olvasó észre fogja venni, hogy a fenti hosszú sor a konfiguráció base64 kódolt változata:

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

Ezek a felhasználói adatok a GitLab-ból, amelyeket a Kubernetes fog használni a képek lehúzásához a registry-ből.

Miután mindent elkészítettünk, törölhetjük a jelenlegi (hibásan működő) Dashboard telepítést a következő paranccsal:

$ .\/ctl.sh -d

… és mindent újra telepíthetünk:

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

Itt az ideje belépni a Dashboardba, és megkeresni a meglehetősen archaikus bejelentkezési gombot:

Miután rákattintottunk, a GitLab-ot látjuk, amely felajánlja a bejelentkezést a megszokott oldalunkon (természetesen, ha előtte még nem jelentkeztünk be):

Jelentkezzünk be a GitLab hitelesítő adatainkkal — és minden megtörtént:

A Dashboard lehetőségei

Ha Ön fejlesztő, aki korábban még nem dolgozott Kubernetes-szel, vagy valami okból eddig nem találkozott a Dashboarddal — bemutatom néhány lehetőségét.

Először is, megnézhetjük, hogy "minden zöld":

A podokról elérhetők részletesebb adatok is, például a környezeti változók, a letöltött kép, a futtatási argumentumok és azok állapota:

A deploymentek állapotai láthatók:

… és egyéb részletek:

… valamint lehetőség van a deployment méretezésére is:

A művelet eredménye:

A cikk elején említett egyéb hasznos lehetőségek között szerepel a naplók megtekintése:

… és a kiválasztott pod konténereinek konzoljába való belépési funkció:

Ezen kívül például meg lehet nézni a csomópontok limitjeit/igényét is:

Természetesen ez nem minden lehetőség, de remélem, hogy az általános kép kialakult.

A beépítés és a Dashboard hátrányai

A leírt beépítésnek nincs semmiféle hozzáférés-ellenőrzése. Ezzel minden felhasználó, akinek van bármilyen hozzáférése a GitLabhoz, hozzáfér a Dashboardhoz. A Dashboardban ugyanaz a hozzáférésük van, ami a Dashboard saját jogaival összhangban van, melyekaz RBAC-ban határozhatók meg.

Nyilvánvaló, hogy ez nem mindenkinek megfelelő, de a mi esetünkben elegendőnek bizonyult.

A Dashboardban megjelenő észlelhető hátrányok közül kiemelem a következőket:
nem lehet belépni az init-konténer konzoljába;
nem lehet szerkeszteni a Deploymente-ket és StatefulSeteket, bár ez a ClusterRole-ban módosítható;

a Dashboard kompatibilitása a legújabb Kubernetes verziókkal és a projekt jövője kérdéseket vet fel.

Az utolsó probléma külön figyelmet érdemel.

A Dashboard állapota és alternatíváiA Dashboard K8s verziókhoz való kompatibilitási táblázata, amelyet a projekt legutolsó verziójában mutattak be (v1.10.1

), nem túl biztató: Ennek ellenére létezik (már januárban elfogadták)PR #3476 , amely bejelenti a K8s 1.13 támogatását. Ezen kívül a projekt issue-i között találhatók olyan felhasználók említései is, akik a K8s 1.14 verzióval dolgoznak a panelben. Végül, a kódalap commitjai nem állnak le. Tehát (legalább!) a projekt tényleges állapota nem annyira rossz, mint amilyennek kezdetben tűnhet az hivatalos kompatibilitási táblázatból.

Végül, a Dashboardnak léteznek alternatívái. Ezek között szerepel:

K8Dash — fiatal felület (az első elköteleződések a márciusra datálhatók), már most is jó lehetőségeket kínál, mint például a klaszter aktuális állapotának vizuális megjelenítése és az objektumok kezelése. "Valós idejű felületként" pozicionálják, mivel automatikusan frissíti a megjelenített adatokat, anélkül, hogy frissítenie kellene az oldalt a böngészőben.
OpenShift Console — a Red Hat OpenShift webes felülete, amely viszont más projekt fejlesztéseit is hozza a klaszterébe, ami nem mindenkinek megfelelő.
Kubernator — érdekes projekt, amely alacsonyabb szintű (mint a Dashboard) felületként készült, lehetőséget adva a klaszter összes objektumának megtekintésére. Azonban úgy tűnik, hogy a fejlesztése leállt.
Polaris — szó szerint nemrégiben bejelentett projekt, amely a panel funkcióit egyesíti (megmutatja a klaszter jelenlegi állapotát, de nem kezeli annak objektumait) és az automatikus "legjobb gyakorlatok validálását" (ellenőrzi a klasztert a benne futó Deployments konfigurációinak helyessége szempontjából).

Összegzések helyett

A Dashboard — a Kubernetes klaszterek standard eszköze, amelyeket karbantartunk. A GitLab-bal való integrációja szintén része lett az "alapértelmezett telepítésünknek", mivel sok fejlesztő örömmel használja a panel által nyújtott lehetőségeket.

A Kubernetes Dashboard alternatívái időről időre megjelennek az Open Source közösségtől (és örömmel várunk minden lehetőséget), de jelen szakaszban ezzel a megoldással maradunk.