Kubernetes Dashboard è uno strumento facile da usare per ottenere informazioni aggiornate sul cluster in esecuzione e per una gestione minima. Inizi a comprenderne il valore ancor di più quando l'accesso a queste funzionalità è necessario non solo per gli amministratori o per ingegneri DevOps, ma anche per coloro che sono meno abituati alla console e/o non intendono approfondire tutte le sottigliezze dell'interazione con kubectl e altre utility. È successo anche a noi: gli sviluppatori volevano un accesso rapido all'interfaccia web di Kubernetes e poiché utilizziamo GitLab, la soluzione è venuta da sé.
Perché farlo?
Gli sviluppatori stessi potrebbero essere interessati a uno strumento come K8s Dashboard per compiti di debug. A volte è utile visualizzare i registri e le risorse, altre volte è necessario terminare i pod, scalare Deployments/StatefulSets e persino accedere alla console dei contenitori (si verificano anche richieste di questo tipo, per le quali però esiste un altro modo — ad esempio, attraverso ).
Inoltre, c'è anche un aspetto psicologico per i dirigenti, che vogliono dare un'occhiata al cluster — vedere che "tutto è verde" e quindi rassicurarsi che "tutto funziona" (cosa, ovviamente, piuttosto relativa… ma questo è già al di fuori dell'argomento di questo articolo).
Come sistema CI standard utilizziamo GitLab: lo utilizzano anche tutti gli sviluppatori. Quindi, per fornire loro l'accesso, è stato logico integrare il Dashboard con gli account di GitLab.
Inoltre, segnalo che utilizziamo NGINX Ingress. Se lavorate con altre , dovrete trovare autonomamente degli equivalenti per le annotazioni di autorizzazione.
Proviamo l'integrazione
Installazione del Dashboard
Attenzione: Se intendete ripetere i passaggi descritti di seguito, leggete prima fino al successivo sottotitolo, per evitare operazioni superflue.
Poiché questa integrazione è utilizzata da noi in molte installazioni, abbiamo automatizzato la sua installazione. I file di origine necessari a questo proposito sono pubblicati in . Alla base ci sono configurazioni YAML leggermente modificate dell' , oltre a uno script Bash per un rapido dispiegamento.
Lo script installa il Dashboard nel cluster e lo configura per l'integrazione con GitLab:
$ ./ctl.sh
Uso: ctl.sh [OPZIONE]... --gitlab-url GITLAB_URL --oauth2-id ID --oauth2-secret SEGRETO --dashboard-url DASHBOARD_URL
Installa kubernetes-dashboard nel cluster Kubernetes.
Argomenti obbligatori:
-i, --install installa nel namespace 'kube-system'
-u, --upgrade aggiorna l'installazione esistente, riutilizzerà password e nomi host
-d, --delete rimuovi tutto, incluso il namespace
--gitlab-url imposta l'url di gitlab con schema (https://gitlab.example.com)
--oauth2-id imposta l'OAUTH2_PROXY_CLIENT_ID di gitlab
--oauth2-secret imposta l'OAUTH2_PROXY_CLIENT_SECRET di gitlab
--dashboard-url imposta l'url del dashboard senza schema (dashboard.example.com)
Argomenti opzionali:
-h, --help visualizza questo messaggioTuttavia, prima di utilizzarlo, è necessario accedere a GitLab: Area di amministrazione → Applicazioni — e aggiungere una nuova applicazione per il futuro pannello. Chiamiamola «kubernetes dashboard»:
A seguito della sua aggiunta, GitLab fornirà gli hash:
Questi vengono utilizzati come argomenti per lo script. Di conseguenza, l'installazione appare come segue:
$ ./ctl.sh -i --gitlab-url https://gitlab.example.com --oauth2-id 6a52769e… --oauth2-secret 6b79168f… --dashboard-url dashboard.example.comDopo di che, verifichiamo che tutto sia partito:
$ kubectl -n kube-system get pod | egrep '(dash|oauth)'
kubernetes-dashboard-76b55bc9f8-xpncp 1/1 In esecuzione 0 14s
oauth2-proxy-5586ccf95c-czp2v 1/1 In esecuzione 0 14sPrima o poi tutto si avvierà, tuttavia l'autenticazione non funzionerà immediatamente! È una questione di fatto, che nell'immagine utilizzata (la situazione è simile in altre immagini) il processo di cattura del redirect nel callback è implementato in modo errato. Questo porta al fatto che oauth cancella il cookie, che esso stesso (oauth) ci fornisce...
Il problema viene risolto costruendo la propria immagine oauth con una patch.
Patch a oauth e reinstallazione
Per questo 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" ]Ecco come appare la patch stessa 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 "... esecuzione dei test"
-.\/test.sh
+#.\/test.sh
-per os in windows linux darwin; do
- echo "... costruzione v$version per $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
-fatto
+os='linux'
+echo "... costruzione v$version per $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 è possibile costruire l'immagine e 'pusharla' nel nostro stesso GitLab. Proseguendo in manifests/kube-dashboard-oauth2-proxy.yaml indicheremo l'utilizzo dell'immagine necessaria (sostituiscila con la tua):
image: docker.io/colemickens/oauth2_proxy:latestSe hai un registro protetto da autenticazione — non dimenticare di aggiungere l'utilizzo del segreto per il pull delle immagini:
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/dockercfgIl lettore attento noterà che la lunga stringa sopra — è la base64 della configurazione:
{"registry.company.com": {
"username": "oauth2",
"password": "PASSWORD",
"auth": "AUTH_TOKEN",
"email": "mail@company.com"
}
}Questi sono i dati dell'utente in GitLab, con i quali Kubernetes effettuerà il pull dell'immagine dal registro.
Dopo che tutto è stato fatto, puoi rimuovere l'attuale installazione (non funzionante) del Dashboard eseguendo il comando:
$ .\/ctl.sh -d… e reinstallare tutto:
$ ./ctl.sh -i --gitlab-url https://gitlab.example.com --oauth2-id 6a52769e… --oauth2-secret 6b79168f… --dashboard-url dashboard.example.comÈ arrivato il momento di accedere al Dashboard e trovare il pulsante di autorizzazione piuttosto arcaico:
Dopo aver cliccato su di esso, ci incontrerà GitLab, offrendoci di autenticarci sulla sua pagina abituale (ovviamente, se non eravamo già autenticati lì):
Autenticati con le credenziali di GitLab — e tutto è compiuto:
Sulle funzionalità del Dashboard
Se sei uno sviluppatore che non ha mai lavorato con Kubernetes, o per qualche motivo non hai mai incontrato prima il Dashboard, ti illustrerò alcune delle sue funzionalità.
Innanzitutto, puoi vedere che "è tutto verde":
Per i pod sono disponibili dati più dettagliati, come le variabili d'ambiente, l'immagine scaricata, gli argomenti di avvio e il loro stato:
Per i deployment sono visibili gli stati:
… e altri dettagli:
… e c'è anche la possibilità di ridimensionare il deployment:
Il risultato di questa operazione:
Tra le altre possibilità utili già menzionate all'inizio dell'articolo, c'è la visualizzazione dei log:
… e la funzione di accesso alla console dei container del pod selezionato:
Inoltre, ad esempio, puoi vedere anche i limiti / richieste sui nodi:
Certo, queste non sono tutte le funzionalità del pannello, ma spero che si sia creata un'idea generale.
Svantaggi dell'integrazione e del Dashboard
Nell'integrazione descritta non c'è alcuna distinzione di accesso. Con essa, tutti gli utenti che hanno accesso a GitLab accedono anche al Dashboard. L'accesso nel Dashboard stesso è lo stesso per tutti, corrispondente ai diritti del Dashboard stesso, che . È evidente che questo non andrà bene per tutti, ma per il nostro caso si è rivelato sufficiente.
Tra i difetti più evidenti del pannello Dashboard, segnalo i seguenti:
- non è possibile accedere alla console del container init;
- non è possibile modificare i Deployments e gli StatefulSets, anche se questo è corretto nella ClusterRole;
- la compatibilità del Dashboard con le ultime versioni di Kubernetes e il futuro del progetto solleva interrogativi.
L'ultimo problema merita particolare attenzione.
Stato e alternative del Dashboard
La tabella di compatibilità del Dashboard con le release di Kubernetes, presentata nell'ultima versione del progetto (), non è molto incoraggiante:
Nonostante ciò, esiste (già approvato a gennaio) , che annuncia il supporto per K8s 1.13. Inoltre, tra i problemi del progetto è possibile trovare riferimenti a utenti che lavorano con il pannello in K8s 1.14. Infine, sulla base di codice del progetto non si fermano. Quindi (almeno!) lo stato reale del progetto non è così brutto come potrebbe sembrare inizialmente dalla tabella ufficiale di compatibilità.
Infine, il Dashboard ha delle alternative. Tra queste:
- — interfaccia giovane (i primi commit risalgono a marzo di quest'anno), già offre buone funzionalità, come la visualizzazione dello stato attuale del cluster e la gestione dei suoi oggetti. Si posiziona come "interfaccia in tempo reale", poiché aggiorna automaticamente i dati visualizzati, senza necessità di aggiornare la pagina nel browser.
- — interfaccia web di Red Hat OpenShift, che però porterà nel tuo cluster anche altre funzionalità del progetto, il che potrebbe non andare bene per tutti.
- — interessante progetto, creato come interfaccia di livello più basso (rispetto al Dashboard) con la possibilità di visualizzare tutti gli oggetti del cluster. Tuttavia, sembra che lo sviluppo sia stato interrotto.
- — letteralmente nei giorni scorsi progetto, che combina le funzioni di un pannello (visualizza lo stato attuale del cluster, ma non gestisce i suoi oggetti) e la "validazione automatica delle best practices" (controlla il cluster per verificare la correttezza delle configurazioni dei Deployments attivi).
Invece delle conclusioni
Dashboard — strumento standard per i cluster Kubernetes che gestiamo. La sua integrazione con GitLab è diventata parte della nostra "installazione predefinita", poiché molti sviluppatori apprezzano le possibilità che questa interfaccia offre loro.
Al Dashboard di Kubernetes emergono periodicamente alternative dalla comunità Open Source (e siamo felici di considerarle), ma in questo momento rimaniamo con questa soluzione.
P.S.
Leggi anche nel nostro blog:
- «»;
- «»;
- «»;
- «».
Fonte: habr.com
