Integració de Kubernetes Dashboard i usuaris de GitLab

Kubernetes Dashboard és una eina fàcil d'utilitzar per obtenir informació actualitzada sobre un clúster en execució i una gestió mínima d'aquest. Comenceu a apreciar-ho encara més quan l'accés a aquestes capacitats és necessari no només per als administradors/enginyers de DevOps, sinó també per a aquells que estan menys acostumats a la consola i/o no tenen la intenció de fer front a totes les complexitats de la interacció amb kubectl i altres utilitats. Això va passar amb nosaltres: els desenvolupadors volien un accés ràpid a la interfície web de Kubernetes i, com que fem servir GitLab, la solució va sorgir de manera natural.

Per què és això?

Els desenvolupadors directes poden estar interessats en una eina com K8s Dashboard per a tasques de depuració. De vegades, voleu veure registres i recursos, i de vegades matar pods, escalar desplegaments/StatefulSets i fins i tot anar a la consola del contenidor (també hi ha sol·licituds d'aquest tipus, per a les quals, però, hi ha una altra manera, per exemple, a través de kubectl-debug).

A més, hi ha un moment psicològic per als directius quan volen mirar el clúster: veure que “tot és verd”, i així assegurar-se que “tot funciona” (que, és clar, és molt relatiu... però això està fora de l'abast de l'article).

Com a sistema CI estàndard tenim aplicat GitLab: tots els desenvolupadors també l'utilitzen. Per tant, per proporcionar-los accés, era lògic integrar Dashboard amb els comptes de GitLab.

També notaré que utilitzem NGINX Ingress. Si treballes amb altres solucions d'entrada, haureu de trobar de manera independent anàlegs d'anotacions per a l'autorització.

Intentant la integració

Instal·lació del quadre de comandament

Atenció: Si voleu repetir els passos següents, per evitar operacions innecessàries, llegiu primer el següent subtítol.

Com que utilitzem aquesta integració en moltes instal·lacions, hem automatitzat la seva instal·lació. Les fonts necessàries per a això es publiquen a repositori especial de GitHub. Es basen en configuracions YAML lleugerament modificades de repositori oficial del Dashboard, així com un script Bash per a un desplegament ràpid.

L'script instal·la Dashboard al clúster i el configura per a la integració amb 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

Tanmateix, abans d'utilitzar-lo, heu d'anar a GitLab: Àrea d'administració → Aplicacions - i afegir una nova aplicació per al panell futur. Diguem-ho "tauler de control de Kubernetes":

Com a resultat d'afegir-lo, GitLab proporcionarà els hash:

Són els que s'utilitzen com a arguments del guió. Com a resultat, la instal·lació té aquest aspecte:

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

Després d'això, comprovem que tot va començar:

$ 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

Tard o d'hora tot començarà, però l'autorització no funcionarà immediatament! El fet és que a la imatge utilitzada (la situació en altres imatges és semblant) el procés de captura d'una redirecció a la devolució de trucada s'implementa incorrectament. Aquesta circumstància porta al fet que oauth esborri la galeta que ens proporciona oauth mateix...

El problema es resol creant la vostra pròpia imatge d'auth amb un pedaç.

Apliqueu oauth i torneu a instal·lar-lo

Per fer-ho, utilitzarem el següent 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" ]

I aquí teniu l'aspecte del propi pegat 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

Ara podeu crear la imatge i introduir-la al nostre GitLab. A continuació en manifests/kube-dashboard-oauth2-proxy.yaml indiqueu l'ús de la imatge desitjada (substituïu-la per la vostra):

 image: docker.io/colemickens/oauth2_proxy:latest

Si teniu un registre que està tancat per autorització, no us oblideu d'afegir l'ús d'un secret per a les imatges d'extracció:

      imagePullSecrets:
     - name: gitlab-registry

... i afegiu el propi secret per al registre:

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

El lector atent veurà que la cadena llarga de dalt és base64 de la configuració:

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

Aquestes són les dades de l'usuari a GitLab, el codi de Kubernetes traurà la imatge del registre.

Un cop fet tot, podeu eliminar la instal·lació actual del tauler de control (no funciona correctament) amb l'ordre:

$ ./ctl.sh -d

... i torna a instal·lar-ho tot:

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

És hora d'anar al Tauler i trobar un botó d'inici de sessió força arcaic:

Després de fer-hi clic, GitLab ens saludarà, oferint-nos iniciar sessió a la seva pàgina habitual (per descomptat, si no hi hem accedit prèviament):

Iniciem sessió amb les credencials de GitLab i tot està fet:

Sobre les funcions del tauler de control

Si sou un desenvolupador que no ha treballat amb Kubernetes abans, o simplement per algun motiu no heu trobat Dashboard abans, us il·lustraré algunes de les seves capacitats.

En primer lloc, podeu veure que "tot és verd":

També hi ha dades més detallades disponibles per als pods, com ara variables d'entorn, imatge baixada, arguments de llançament i el seu estat:

Els desplegaments tenen estats visibles:

...i altres detalls:

... i també hi ha la possibilitat d'escalar el desplegament:

El resultat d'aquesta operació:

Entre altres funcions útils ja esmentades al principi de l'article hi ha la visualització dels registres:

... i la funció per iniciar sessió a la consola del contenidor del pod seleccionat:

Per exemple, també podeu mirar els límits/sol·licituds als nodes:

Per descomptat, aquestes no són totes les capacitats del panell, però espero que tingueu una idea general.

Inconvenients de la integració i Dashboard

En la integració descrita no hi ha control d'accés. Amb ell, tots els usuaris amb qualsevol accés a GitLab tenen accés al Dashboard. Tenen el mateix accés al mateix Dashboard, corresponent als drets del mateix Dashboard, que es defineixen a RBAC. Evidentment, això no és apte per a tothom, però per al nostre cas va resultar ser suficient.

Entre els desavantatges notables del tauler de control, destaco el següent:

• és impossible entrar a la consola del contenidor init;
• és impossible editar Deployments i StatefulSets, encara que això es pot solucionar a ClusterRole;
• La compatibilitat de Dashboard amb les últimes versions de Kubernetes i el futur del projecte planteja preguntes.

L'últim problema mereix una atenció especial.

Estat del tauler i alternatives

Taula de compatibilitat del tauler de control amb versions de Kubernetes, presentada a la darrera versió del projecte (v1.10.1), no gaire content:

Malgrat això, hi ha (ja adoptat al gener) PR # 3476, que anuncia suport per a K8s 1.13. A més, entre els problemes del projecte podeu trobar referències a usuaris que treballen amb el panell a K8s 1.14. Finalment, es compromet a la base de codi del projecte no s'atura. Així (almenys!) L'estat real del projecte no és tan dolent com podria semblar a primera vista a la taula de compatibilitat oficial.

Finalment, hi ha alternatives al Dashboard. Entre ells:

1. K8 Dash — una interfície jove (els primers compromisos es remunten al març d'enguany), que ja ofereix bones característiques, com ara una representació visual de l'estat actual del clúster i la gestió dels seus objectes. Posicionat com una "interfície en temps real", perquè actualitza automàticament les dades mostrades sense que cal que actualitzeu la pàgina al navegador.
2. Consola OpenShift - una interfície web de Red Hat OpenShift, que, però, portarà altres desenvolupaments del projecte al vostre clúster, que no és apte per a tothom.
3. Kubernator és un projecte interessant, creat com una interfície de nivell inferior (que el Dashboard) amb la possibilitat de veure tots els objectes del clúster. Tanmateix, sembla que el seu desenvolupament s'ha aturat.
4. Estrella polar - just l'altre dia va anunciar un projecte que combina les funcions d'un panell (mostra l'estat actual del clúster, però no gestiona els seus objectes) i la "validació de bones pràctiques" automàtica (comprova el clúster per a la correcció de les configuracions dels Desplegaments que s'hi executen).

En lloc de conclusions

Dashboard és una eina estàndard per als clústers de Kubernetes que servim. La seva integració amb GitLab també s'ha convertit en part de la nostra instal·lació predeterminada, ja que molts desenvolupadors estan entusiasmats amb les capacitats que tenen amb aquest panell.

Kubernetes Dashboard té periòdicament alternatives de la comunitat de codi obert (i estem encantats de considerar-les), però en aquesta etapa continuem amb aquesta solució.

PS

Llegeix també al nostre blog:

• «kubebox i altres shells per a Kubernetes»;
• «Millors pràctiques de CI/CD amb Kubernetes i GitLab (revisió i informe de vídeo)»;
• «Creeu i implementeu aplicacions a Kubernetes mitjançant dapp i GitLab CI»;
• «GitLab CI per a la integració i el lliurament contínues en producció. Part 1: el nostre gasoducte».

Font: www.habr.com