Integrazione di Kubernetes Dashboard e utenti GitLab

Kubernetes Dashboard è uno strumento facile da usare per ottenere informazioni aggiornate sul tuo cluster in esecuzione e gestirlo con il minimo sforzo. Si inizia ad apprezzarlo ancora di più quando l'accesso a queste funzionalità è necessario non solo agli amministratori/ingegneri DevOps, ma anche a coloro che sono meno abituati alla console e/o non intendono affrontare tutte le complessità dell'interazione con kubectl e altre utilità. A noi è successo questo: gli sviluppatori volevano un accesso rapido all'interfaccia web di Kubernetes e, poiché utilizziamo GitLab, la soluzione è arrivata naturalmente.

Perché questo?

Gli sviluppatori diretti potrebbero essere interessati a uno strumento come K8s Dashboard per le attività di debug. A volte vuoi visualizzare log e risorse, a volte kill pod, scalare Deployments/StatefulSet e persino andare alla console del container (ci sono anche richieste per le quali, tuttavia, esiste un altro modo, ad esempio tramite kubectl-debug).

Inoltre, c'è un momento psicologico per i manager quando vogliono guardare il cluster - per vedere che "tutto è verde", e quindi rassicurarsi che "tutto funziona" (il che, ovviamente, è molto relativo... ma questo esula dallo scopo dell'articolo).

Come sistema CI standard abbiamo applicare GitLab: lo usano anche tutti gli sviluppatori. Pertanto, per fornire loro l'accesso, era logico integrare Dashboard con gli account GitLab.

Noterò anche che utilizziamo NGINX Ingress. Se lavori con gli altri soluzioni di ingresso, dovrai trovare in modo indipendente analoghi di annotazioni per l'autorizzazione.

Provare l'integrazione

Installazione del cruscotto

Attenzione: Se avete intenzione di ripetere i passaggi seguenti, allora - per evitare operazioni inutili - leggete prima il sottotitolo successivo.

Poiché utilizziamo questa integrazione in molte installazioni, ne abbiamo automatizzato l'installazione. Le fonti necessarie a questo scopo sono pubblicate in repository GitHub speciale. Si basano su configurazioni YAML leggermente modificate da repository ufficiale della dashboard, nonché uno script Bash per una distribuzione rapida.

Lo script installa Dashboard nel cluster e lo configura per l'integrazione con 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

Tuttavia, prima di utilizzarlo, devi andare su GitLab: area di amministrazione → Applicazioni - e aggiungere una nuova applicazione per il pannello futuro. Chiamiamolo "dashboard Kubernetes":

Come risultato dell'aggiunta, GitLab fornirà gli hash:

Sono quelli che vengono utilizzati come argomenti nello script. Di conseguenza, l'installazione si presenta così:

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

Fatto ciò, controlliamo che tutto sia iniziato:

$ 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

Prima o poi tutto inizierà, però l'autorizzazione non funzionerà immediatamente! Il fatto è che nell'immagine utilizzata (la situazione in altre immagini è simile) il processo di acquisizione di un reindirizzamento nel callback è implementato in modo errato. Questa circostanza porta al fatto che oauth cancella il cookie che oauth stesso ci fornisce...

Il problema viene risolto costruendo la propria immagine OAuth con una patch.

Patch oauth e reinstallare

Per fare ciò, utilizzeremo il seguente 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" ]

Ed ecco come appare la patch rd.patch stessa

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

Ora puoi creare l'immagine e inserirla nel nostro GitLab. Avanti manifests/kube-dashboard-oauth2-proxy.yaml indicare l'utilizzo dell'immagine desiderata (sostituirla con la propria):

 image: docker.io/colemickens/oauth2_proxy:latest

Se hai un registro chiuso per autorizzazione, non dimenticare di aggiungere l'uso di un segreto per le immagini pull:

      imagePullSecrets:
     - name: gitlab-registry

... e aggiungi il segreto stesso per il registro:

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

Il lettore attento vedrà che la lunga stringa sopra è base64 dalla configurazione:

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

Questi sono i dati utente in GitLab, il codice Kubernetes estrarrà l'immagine dal registro.

Al termine, puoi rimuovere l'installazione corrente (che non funziona correttamente) della Dashboard con il comando:

$ ./ctl.sh -d

... e installa di nuovo tutto:

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

È ora di andare sulla Dashboard e trovare un pulsante di accesso piuttosto arcaico:

Dopo aver cliccato su di esso, GitLab ci accoglierà, offrendoci di accedere alla sua solita pagina (ovviamente, se non vi abbiamo precedentemente effettuato l'accesso):

Effettuiamo l'accesso con le credenziali GitLab - e tutto è fatto:

Informazioni sulle funzionalità della dashboard

Se sei uno sviluppatore che non ha mai lavorato con Kubernetes o semplicemente per qualche motivo non hai mai utilizzato Dashboard, ti illustrerò alcune delle sue funzionalità.

Innanzitutto puoi vedere che “tutto è verde”:

Sono disponibili anche dati più dettagliati per i pod, come variabili di ambiente, immagine scaricata, argomenti di avvio e relativo stato:

Le distribuzioni hanno stati visibili:

...e altri dettagli:

... e c'è anche la possibilità di scalare la distribuzione:

Il risultato di questa operazione:

Tra le altre utili funzionalità già menzionate all'inizio dell'articolo c'è la visualizzazione dei registri:

... e la funzione per accedere alla console del contenitore del pod selezionato:

Ad esempio, puoi anche guardare i limiti/richieste sui nodi:

Naturalmente queste non sono tutte le funzionalità del pannello, ma spero che tu abbia un'idea generale.

Svantaggi dell'integrazione e della Dashboard

Nell'integrazione descritta non c'è controllo di accesso. Con esso, tutti gli utenti con qualsiasi accesso a GitLab ottengono l'accesso alla Dashboard. Hanno lo stesso accesso alla Dashboard stessa, corrispondente ai diritti della Dashboard stessa, che sono definiti in RBAC. Ovviamente questo non è adatto a tutti, ma nel nostro caso si è rivelato sufficiente.

Tra gli svantaggi evidenti nella Dashboard stessa, noto quanto segue:

• è impossibile entrare nella console del contenitore init;
• è impossibile modificare Deployments e StatefulSets, anche se questo può essere risolto in ClusterRole;
• La compatibilità di Dashboard con le ultime versioni di Kubernetes e il futuro del progetto sollevano interrogativi.

L'ultimo problema merita un'attenzione speciale.

Stato della dashboard e alternative

Tabella di compatibilità della dashboard con le versioni Kubernetes, presentata nell'ultima versione del progetto (v1.10.1), non molto felice:

Nonostante ciò esiste (già adottato a gennaio) PR # 3476, che annuncia il supporto per K8s 1.13. Inoltre, tra le questioni del progetto si possono trovare riferimenti agli utenti che lavorano con il pannello in K8s 1.14. Finalmente, commette nel codice base del progetto non si fermano. Quindi (almeno!) lo stato attuale del progetto non è così negativo come potrebbe sembrare dalla tabella di compatibilità ufficiale.

Infine, ci sono alternative a Dashboard. Tra loro:

1. K8Dash — un'interfaccia giovane (i primi commit risalgono a marzo di quest'anno), che offre già buone funzionalità, come la rappresentazione visiva dello stato attuale del cluster e la gestione dei suoi oggetti. Posizionato come "interfaccia in tempo reale", perché aggiorna automaticamente i dati visualizzati senza richiedere l'aggiornamento della pagina nel browser.
2. Console OpenShift - un'interfaccia web di Red Hat OpenShift, che però porterà altri sviluppi del progetto nel tuo cluster, che non è adatto a tutti.
3. Kubernator è un progetto interessante, creato come interfaccia di livello inferiore (rispetto a Dashboard) con la possibilità di visualizzare tutti gli oggetti del cluster. Tuttavia, sembra che il suo sviluppo si sia fermato.
4. Polaris - proprio l'altro giorno annunciato un progetto che combina le funzioni di un pannello (mostra lo stato attuale del cluster, ma non ne gestisce gli oggetti) e di “convalida automatica delle migliori pratiche” (controlla il cluster per la correttezza delle configurazioni dei Deployment in esecuzione al suo interno).

Invece di conclusioni

Dashboard è uno strumento standard per i cluster Kubernetes che serviamo. Anche la sua integrazione con GitLab è diventata parte della nostra installazione predefinita, poiché molti sviluppatori sono entusiasti delle funzionalità di cui dispone questo pannello.

Kubernetes Dashboard dispone periodicamente di alternative dalla comunità Open Source (e siamo felici di prenderle in considerazione), ma in questa fase rimaniamo con questa soluzione.

PS

Leggi anche sul nostro blog:

• «kubebox e altre shell per Kubernetes";
• «Migliori pratiche CI/CD con Kubernetes e GitLab (revisione e rapporto video)";
• «Crea e distribuisci applicazioni in Kubernetes utilizzando dapp e GitLab CI";
• «GitLab CI per l'integrazione e la distribuzione continua in produzione. Parte 1: la nostra pipeline'.

Fonte: habr.com