Integracija Kubernetes Dashboard in uporabnikov GitLab

Kubernetes Dashboard je enostavno orodje za pridobivanje aktualnih informacij o delujocem klastru in minimalno upravljanje z njim. Še bolj ga cenite, ko dostop do teh možnosti potrebujete ne le administratorji/DevOps inženirji, ampak tudi tisti, ki niso navajeni dela s konzolo in/ali ne nameravajo podrobno raziskovati vseh odtenkov interakcije z kubectl in drugimi pripomočki. Tako smo se znašli tudi mi: razvijalcem je želel hiter dostop do spletnega vmesnika Kubernetes, in ker uporabljamo GitLab, se je rešitev sama ponudila.

Zakaj to?

Neposredni razvijalci so lahko zainteresirani za orodje, kot je K8s Dashboard, za naloge odpravljanja napak. Včasih želite pregledati dnevniške datoteke in vire, včasih pa ubiti pod-e, skalirati Deployments/StatefulSets in celo vstopiti v konzolo vsebin (takšni zahtevki se dogajajo, za reševanje katerih pa obstaja druga pot — na primer, preko kubectl-debug).

Poleg tega obstaja tudi psihološki vidik za vodje, ko želijo pogledati klaster — videti, da je "vse zeleno", in tako se pomiriti, da "vse deluje" (kar je seveda precej relativno… ampak to že presega okvir članka).

Kot standardni CI-sistem imamo se uporablja GitLab: ga uporabljajo vsi razvijalci. Zato se je zdelo logično nuditi jim dostop, tako da smo integrirali Dashboard z računi v GitLab.

Prav tako želim poudariti, da uporabljamo NGINX Ingress. Če pa delate z drugimi ingress-rešitvami, boste morali sami poiskati analoge anotacij za avtentikacijo.

Preizkušamo integracijo

Namestitev Dashboard

Opozorilo: Če se nameravate ponoviti opisane korake, torej — da bi se izognili nepotrebnim operacijam — najprej preberite do naslednje podnaslova.

Ker to integracijo uporabljamo v številnih namestitvah, smo avtomatizirali njeno namestitev. Izvorne datoteke, ki jih potrebujete za to, so objavljene v posebnem GitHub repozitoriju. Njihova osnova so rahlo modificirane YAML konfiguracije iz uradnega repozitorija Dashboard, prav tako pa Bash skript za hitro uvajanje.

Skript namesti Dashboard v klaster in ga nastavi za integracijo z 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

Vendar pred njegovo uporabo se morate prijaviti v GitLab: Administratorsko področje → Aplikacije — in dodati novo aplikacijo za prihodnjo nadzorno ploščo. Poimenujmo jo „kubernetes nadzorna plošča“:

Kot rezultat njegovega dodajanja, bo GitLab zagotovil hashes:

To so tisti, ki se uporabljajo kot argumenti skriptu. Tako bo namestitev videti takole:

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

Po tem preverimo, da je vse zagnano:

$ 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

Prej ali slej se bo vse zagnalo, vendar takoj avtentikacija ne bo delovala! Gre za to, da je v uporabljeni podobi (situacija pri drugih podobah je podobna) postopek zajema preusmeritve v povratnem klicu nepravilno izveden. To dejstvo povzroči, da oauth izbriše piškotek, ki ga sam (oauth) zagotavlja…

Težava se reši z gradnjo svoje podobe oauth s popravkom.

Popravek za oauth in ponovna namestitev

Za to uporabimo naslednji 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" ]

In tako izgleda sam popravek 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 "... выполняем тесты"
-.\/test.sh
+#.\/test.sh
 
-for os in windows linux darwin; do
-    echo "... сборка v$version для $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 "... сборка v$version для $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

Теперь можно осуществить сборку образа и запушить его в наш же GitLab. Далее в manifests/kube-dashboard-oauth2-proxy.yaml укажем использование нужного образа (замените его на свой):

 image: docker.io/colemickens/oauth2_proxy:latest

Если у вас закрытый регистр с авторизацией — не забудьте добавить использование секрета для вытягивания образов:

      imagePullSecrets:
     - name: gitlab-registry

… и добавьте сам секрет для регистра:

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

Внимательный читатель заметит, что приведённая выше длинная строка — это base64 от конфигурации:

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

Это данные пользователя в GitLab, по которым Kubernetes будет вытягивать образ из регистра.

После того как всё сделано, можно удалить текущую (некорректно работающую) инсталляцию Dashboard командой:

$ ./ctl.sh -d

… и установить всё заново:

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

Настало время зайти в Dashboard и найти довольно устаревшую кнопку авторизации:

После нажатия на неё нас встретит GitLab, предлагая авторизоваться на своей привычной странице (конечно же, если мы не были предварительно авторизованы там):

Авторизуемся с учётными данными GitLab — и всё свершилось:

О возможностях Dashboard

Če ste razvijalec, ki še nikoli ni delal s Kubernetesom, ali pa preprosto iz kakšnega razloga še niste naleteli na Dashboard — vam bom ilustriral nekatere njegove možnosti.

Najprej lahko vidite, da je „vse zeleno“:

Za pod'i so na voljo tudi bolj podrobni podatki, kot so okoljske spremenljivke, prenesena slika, zagonski argumenti in njihovo stanje:

Pri deploymentih so vidni statusi:

… in druge podrobnosti:

… prav tako pa je možnost za skaliranje deploymenta:

Rezultat te operacije:

Med drugimi koristnimi možnostmi, že omenjenimi na začetku članka, je tudi pregled logov:

… in funkcija dostopa do konzole kontejnerjev izbranega poda:

Poleg tega lahko na primer preverite tudi omejitve/zahtave na vozliščih:

Seveda to niso vse možnosti panela, a upam, da ste si ustvarili splošno predstavo.

Pomanjkljivosti integracije in Dashboard

V opisani integraciji ni nobenega omejevanja dostopa. Z njo vsi uporabniki, ki imajo kakršen koli dostop do GitLab-a, pridobijo dostop do Dashboard-a. Dostop v samem Dashboard-u je enak za vse, kar ustreza pravicam samega Dashboard-a, ki so določene v RBAC. Očitno to ne ustreza vsem, a se je za naš primer izkazalo za dovolj dobro.

Iz vidnih pomanjkljivosti v samem Dashboard-u izpostavljam naslednje:

• ni mogoče dostopati do konzole init-kontejnerja;
• ni mogoče urejati Deployments in StatefulSets, čeprav to lahko popravimo v ClusterRole;
• združljivost Dashboard-a z najnovejšimi različicami Kubernetes-a in prihodnost projekta vzbujata vprašanja.

Zadnji problem zasluži posebno pozornost.

Status in alternative Dashboard-a

Tabela združljivosti Dashboard-a z različicami Kubernetes-a, predstavljena v zadnji različici projekta (v1.10.1), ne navdušuje:

Kljub temu obstaja (že sprejet januarja) PR #3476, ki napoveduje podporo K8s 1.13. Poleg tega med težavami projekta lahko najdete omembe uporabnikov, ki delajo s panelom v K8s 1.14. Na koncu, commits v kodo projekta se še naprej dodajajo. Torej (vsaj!) dejanski status projekta ni tako slab, kot se lahko sprva zdi iz uradne tabele združljivosti.

Nazadnje, Dashboard ima alternative. Med njimi:

1. K8Dash — mladostni vmesnik (prvi commit je bil v marcu letos), ki že ponuja dobre možnosti, kot so vizualni pregled trenutnega stanja grozda in upravljanje z njegovimi objekti. Pozicionira se kot „vmesnik v realnem času“, saj samodejno posodablja prikazane podatke, ne da bi bilo treba osvežiti stran v brskalniku.
2. OpenShift Console — spletni vmesnik Red Hat OpenShift, ki pa prinaša tudi druge dosežke projekta, kar ne ustreza vsem.
3. Kubernator — zanimiv projekt, ustvarjen kot nižje raven (kot Dashboard) vmesnik z možnostjo pregleda vseh objektov grozda. Vendar se zdi, da je razvoj tega projekta prenehal.
4. Polaris — dobesedno pred dnevi napovedan projekt, ki združuje funkcije plošče (prikazuje trenutno stanje grozda, a ne upravlja njegovih objektov) in samodejne „validacije najboljših praks“ (preverja grozd za pravilnosti konfiguracij, ki jih vsebujejo Deployments).

Namesto zaključkov

Dashboard — standardno orodje za Kubernetes grozde, ki jih upravljamo. Njegova integracija z GitLabom je prav tako postala del naše „privzete namestitve“, saj so mnogi razvijalci veseli možnosti, ki jim jih ponuja ta plošča.

Pri Kubernetes Dashboard se občasno pojavijo alternative iz Open Source skupnosti (in z veseljem jih preučujemo), vendar v tem trenutku ostajamo pri tej rešitvi.

P.S.

Preberite tudi na našem blogu:

• «kubebox in druge konzolne lupine za Kubernetes»;
• «Najboljše prakse CI/CD s Kubernetes in GitLab (pregled in video predavanja)»;
• «Sestavljanje in deploy aplikacij v Kubernetesu s pomočjo dapp in GitLab CI»;
• «GitLab CI za neprekinjeno integracijo in dostavo v produkcijo. Del 1: naš pipeline».

Izvor: habr.com