Integración de Kubernetes Dashboard e usuarios de GitLab

Kubernetes Dashboard é unha ferramenta fácil de usar para obter información actualizada sobre o seu clúster en execución e xestionalo cun mínimo esforzo. Comeza a aprecialo aínda máis cando o acceso a estas capacidades é necesario non só para os administradores/enxeñeiros de DevOps, senón tamén para aqueles que están menos afeitos á consola e/ou non teñen a intención de xestionar todas as complejidades de interactuar con kubectl e outras utilidades. Isto pasou connosco: os desenvolvedores querían un acceso rápido á interface web de Kubernetes e, como usamos GitLab, a solución veu natural.

Por que isto?

Os desenvolvedores directos poden estar interesados ​​nunha ferramenta como K8s Dashboard para tarefas de depuración. Ás veces quere ver rexistros e recursos, e ás veces matar pods, escalar Implementos/StatefulSets e mesmo ir á consola do contedor (tamén hai solicitudes para as que, con todo, hai outro xeito, por exemplo, a través de kubectl-debug).

Ademais, hai un momento psicolóxico para os directivos cando queren mirar o clúster -ver que “todo é verde”, e así asegurarse de que “todo está funcionando” (que, por suposto, é moi relativo... pero isto está fóra do alcance do artigo).

Como sistema estándar de CI temos aplicado GitLab: todos os desenvolvedores tamén o usan. Polo tanto, para proporcionarlles acceso, era lóxico integrar Dashboard coas contas de GitLab.

Tamén notarei que usamos NGINX Ingress. Se traballas con outros solucións de entrada, terá que atopar de forma independente análogos de anotacións para a autorización.

Probando a integración

Instalación de panel de control

Atención: Se vai repetir os pasos seguintes, entón - para evitar operacións innecesarias - lea primeiro o seguinte subtítulo.

Dado que utilizamos esta integración en moitas instalacións, automatizamos a súa instalación. As fontes necesarias para iso publícanse en repositorio especial de GitHub. Están baseados en configuracións YAML lixeiramente modificadas de repositorio oficial de Dashboard, así como un script Bash para unha implementación rápida.

O script instala Dashboard no clúster e configúrao para a súa integración 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

Non obstante, antes de usalo, cómpre ir a GitLab: Área de administración → Aplicacións - e engadir unha nova aplicación para o panel futuro. Chamémoslle "panel de control de kubernetes":

Como resultado de engadilo, GitLab proporcionará os hash:

Son os que se utilizan como argumentos para o guión. Como resultado, a instalación ten o seguinte aspecto:

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

Despois diso, comprobamos que todo comezou:

$ 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

Porén, tarde ou cedo todo comezará a autorización non funcionará inmediatamente! O caso é que na imaxe utilizada (a situación noutras imaxes é similar) o proceso de captura dunha redirección na devolución de chamada está implementado incorrectamente. Esta circunstancia leva a que oauth borra a cookie que o propio oauth nos proporciona...

O problema resólvese construíndo a túa propia imaxe de oauth cun parche.

Parche oauth e reinstala

Para iso, utilizaremos o seguinte 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" ]

E aquí está o aspecto do propio parche 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

Agora podes construír a imaxe e introducila no noso GitLab. A continuación en manifests/kube-dashboard-oauth2-proxy.yaml indica o uso da imaxe desexada (substitúea pola túa):

 image: docker.io/colemickens/oauth2_proxy:latest

Se tes un rexistro que está pechado por autorización, non esquezas engadir o uso dun segredo para as imaxes de extracción:

      imagePullSecrets:
     - name: gitlab-registry

... e engade o propio segredo para o rexistro:

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

O lector atento verá que a longa cadea anterior é base64 da configuración:

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

Estes son os datos do usuario en GitLab, o código de Kubernetes sacará a imaxe do rexistro.

Despois de que todo estea feito, pode eliminar a instalación actual do panel de control (non funciona correctamente) co comando:

$ ./ctl.sh -d

... e instala todo de novo:

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

É hora de ir ao Panel e atopar un botón de inicio de sesión bastante arcaico:

Despois de premer nela, GitLab saudaranos, ofrecéndonos iniciar sesión na súa páxina habitual (por suposto, se non iniciamos sesión previamente alí):

Iniciamos sesión coas credenciais de GitLab e todo está feito:

Acerca das funcións do panel de control

Se es un programador que non traballou con Kubernetes antes, ou simplemente por algún motivo non atopou o Dashboard antes, ilustrarei algunhas das súas capacidades.

En primeiro lugar, podes ver que "todo é verde":

Tamén están dispoñibles datos máis detallados para os pods, como as variables de ambiente, a imaxe descargada, os argumentos de inicio e o seu estado:

Os despregamentos teñen estados visibles:

...e outros detalles:

... e tamén hai a posibilidade de escalar o despregamento:

O resultado desta operación:

Entre outras funcións útiles xa mencionadas ao comezo do artigo está a visualización de rexistros:

... e a función para iniciar sesión na consola do contenedor do pod seleccionado:

Por exemplo, tamén podes ver os límites/solicitudes nos nodos:

Por suposto, estas non son todas as capacidades do panel, pero espero que teñades unha idea xeral.

Desvantaxes da integración e dashboard

Na integración descrita non hai control de acceso. Con el, todos os usuarios con calquera acceso a GitLab acceden ao panel. Teñen o mesmo acceso no propio Dashboard, correspondente aos dereitos do propio Dashboard, que están definidos en RBAC. Obviamente, isto non é apto para todos, pero para o noso caso resultou ser suficiente.

Entre as desvantaxes notables do propio panel, observo o seguinte:

• é imposible entrar na consola do contedor init;
• é imposible editar Deployments e StatefulSets, aínda que isto pódese solucionar en ClusterRole;
• A compatibilidade de Dashboard coas últimas versións de Kubernetes e o futuro do proxecto suscitan dúbidas.

O último problema merece unha atención especial.

Estado do panel e alternativas

Táboa de compatibilidade do panel coas versións de Kubernetes, presentada na última versión do proxecto (v1.10.1), non moi feliz:

A pesar diso, hai (xa adoptado en xaneiro) PR #3476, que anuncia soporte para K8s 1.13. Ademais, entre os problemas do proxecto podes atopar referencias a usuarios que traballan co panel en K8s 1.14. Finalmente, comete no código base do proxecto non se deteña. Entón (polo menos!) O estado real do proxecto non é tan malo como podería parecer desde a táboa oficial de compatibilidade.

Finalmente, hai alternativas ao Dashboard. Entre eles:

1. K8 Dash — unha interface nova (os primeiros compromisos remóntanse a marzo deste ano), que xa ofrece boas características, como unha representación visual do estado actual do clúster e a xestión dos seus obxectos. Posicionado como unha "interface en tempo real", porque actualiza automaticamente os datos mostrados sen necesidade de que actualice a páxina no navegador.
2. Consola OpenShift - unha interface web de Red Hat OpenShift, que, porén, achegará outros desenvolvementos do proxecto ao seu clúster, que non é apto para todos.
3. Kubernator é un proxecto interesante, creado como unha interface de nivel inferior (que o Dashboard) coa capacidade de ver todos os obxectos do clúster. Non obstante, parece que o seu desenvolvemento parou.
4. Polaris - Xusto o outro día anunciou un proxecto que combina as funcións dun panel (amosa o estado actual do clúster, pero non xestiona os seus obxectos) e a "validación das mellores prácticas" automática (comproba o clúster a corrección das configuracións das Implementacións que se executan nel).

En vez de conclusións

O panel é unha ferramenta estándar para os clústeres de Kubernetes aos que servimos. A súa integración con GitLab tamén pasou a formar parte da nosa instalación predeterminada, xa que moitos desenvolvedores están entusiasmados coas capacidades que teñen con este panel.

Kubernetes Dashboard ten periodicamente alternativas da comunidade de código aberto (e estamos encantados de consideralas), pero neste momento seguimos con esta solución.

PS

Lea tamén no noso blog:

• «kubebox e outros shells para Kubernetes»;
• «Mellores prácticas de CI/CD con Kubernetes e GitLab (revisión e informe de vídeo)»;
• «Crea e implementa aplicacións en Kubernetes usando dapp e GitLab CI»;
• «GitLab CI para a integración e entrega continuas na produción. Parte 1: o noso gasoduto».

Fonte: www.habr.com