Integración de Kubernetes Dashboard y GitLab Users

Kubernetes Dashboard es una herramienta fácil de usar para obtener información actualizada sobre su clúster en ejecución y administrarlo con el mínimo esfuerzo. Se empieza a apreciar aún más cuando el acceso a estas capacidades es necesario no solo para los administradores/ingenieros de DevOps, sino también para aquellos que están menos acostumbrados a la consola y/o no tienen la intención de lidiar con todas las complejidades de la interacción con kubectl y otras utilidades. Esto sucedió con nosotros: los desarrolladores querían un acceso rápido a la interfaz web de Kubernetes y, como usamos GitLab, la solución surgió de forma natural.

Porque es esto

Los desarrolladores directos pueden estar interesados ​​en una herramienta como K8s Dashboard para tareas de depuración. A veces desea ver registros y recursos y, a veces, eliminar pods, escalar implementaciones/StatefulSets e incluso ir a la consola del contenedor (también hay solicitudes para las cuales, sin embargo, hay otra forma, por ejemplo, a través de kubectl-depuración).

Además, hay un momento psicológico para los directivos en el que quieren mirar el cluster para ver que “todo está verde” y así asegurarse de que “todo está funcionando” (lo cual, por supuesto, es muy relativo... pero esto está más allá del alcance del artículo).

Como sistema CI estándar tenemos aplica GitLab: todos los desarrolladores también lo usan. Por lo tanto, para brindarles acceso, era lógico integrar Dashboard con las cuentas de GitLab.

También señalaré que utilizamos NGINX Ingress. Si trabajas con otros soluciones de ingreso, deberá buscar de forma independiente análogos de anotaciones para la autorización.

Probando la integración

Instalación del tablero

¡Atención: Si va a repetir los pasos siguientes, (para evitar operaciones innecesarias) lea primero el siguiente subtítulo.

Dado que utilizamos esta integración en muchas instalaciones, hemos automatizado su instalación. Las fuentes necesarias para esto están publicadas en repositorio especial de GitHub. Se basan en configuraciones YAML ligeramente modificadas de repositorio oficial del panel, así como un script Bash para una implementación rápida.

El script instala Dashboard en el clúster y lo configura para su 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

Sin embargo, antes de usarlo, debe ir a GitLab: Área de administración → Aplicaciones - y agregar una nueva aplicación para el panel futuro. Llamémoslo "panel de control de Kubernetes":

Como resultado de agregarlo, GitLab proporcionará los hashes:

Son los que se utilizan como argumentos del guión. Como resultado, la instalación se ve así:

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

Después de eso, comprobemos que todo empezó:

$ 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

Tarde o temprano todo empezará, sin embargo. la autorización no funcionará inmediatamente! El hecho es que en la imagen utilizada (la situación en otras imágenes es similar) el proceso de captar una redirección en la devolución de llamada se implementa incorrectamente. Esta circunstancia lleva a que oauth borre la cookie que la propia oauth nos proporciona…

El problema se resuelve construyendo su propia imagen oauth con un parche.

Parchear oauth y reinstalar

Para ello utilizaremos el siguiente 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" ]

Y así es como se ve el 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

Ahora puedes crear la imagen y enviarla a nuestro GitLab. Siguiente en manifests/kube-dashboard-oauth2-proxy.yaml indique el uso de la imagen deseada (reemplácela por la suya propia):

 image: docker.io/colemickens/oauth2_proxy:latest

Si tienes un registro que está cerrado por autorización, no olvides agregar el uso de un secreto para extraer imágenes:

      imagePullSecrets:
     - name: gitlab-registry

... y agregue el secreto mismo para el registro:

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

El lector atento verá que la cadena larga de arriba es base64 de la configuración:

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

Estos son los datos del usuario en GitLab, el código de Kubernetes extraerá la imagen del registro.

Una vez hecho todo, puede eliminar la instalación actual del Panel de control (que no funciona correctamente) con el comando:

$ ./ctl.sh -d

... e instalar todo de nuevo:

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

Es hora de ir al Panel y encontrar un botón de inicio de sesión bastante arcaico:

Tras pulsar sobre él, GitLab nos saludará ofreciéndonos iniciar sesión en su página habitual (claro, si no hemos iniciado sesión allí previamente):

Iniciamos sesión con las credenciales de GitLab y todo está hecho:

Acerca de las funciones del panel

Si es un desarrollador que no ha trabajado antes con Kubernetes, o simplemente por alguna razón no ha encontrado Dashboard antes, le ilustraré algunas de sus capacidades.

En primer lugar, puedes ver que “todo es verde”:

También hay datos más detallados disponibles para los pods, como variables de entorno, imágenes descargadas, argumentos de inicio y su estado:

Las implementaciones tienen estados visibles:

...y otros detalles:

... y también existe la posibilidad de escalar la implementación:

El resultado de esta operación:

Entre otras funciones útiles ya mencionadas al principio del artículo se encuentra la visualización de registros:

... y la función para iniciar sesión en la consola del contenedor del pod seleccionado:

Por ejemplo, también puede consultar los límites/solicitudes en los nodos:

Por supuesto, estas no son todas las capacidades del panel, pero espero que te hagas una idea general.

Desventajas de la integración y el Dashboard

En la integración descrita no hay control de acceso. Con él, todos los usuarios con acceso a GitLab obtienen acceso al Panel. Tienen el mismo acceso en el propio Dashboard, correspondiente a los derechos del propio Dashboard, que están definidos en RBAC. Evidentemente, esto no es apto para todos, pero en nuestro caso resultó suficiente.

Entre las desventajas notables del propio Panel, destaco las siguientes:

• es imposible acceder a la consola del contenedor de inicio;
• es imposible editar Deployments y StatefulSets, aunque esto se puede solucionar en ClusterRole;
• La compatibilidad de Dashboard con las últimas versiones de Kubernetes y el futuro del proyecto plantean dudas.

El último problema merece especial atención.

Estado del panel y alternativas

Tabla de compatibilidad del panel con versiones de Kubernetes, presentada en la última versión del proyecto (v1.10.1), No muy feliz:

A pesar de ello, existe (ya adoptada en enero) PR # 3476, que anuncia soporte para K8s 1.13. Además, entre las ediciones del proyecto se pueden encontrar referencias a usuarios que trabajan con el panel en K8s 1.14. Finalmente, se compromete en el código base del proyecto no se detiene. Así que (¡al menos!) el estado real del proyecto no es tan malo como podría parecer a primera vista en la tabla de compatibilidad oficial.

Finalmente, existen alternativas al Dashboard. Entre ellos:

1. K8Dash — una interfaz joven (las primeras confirmaciones se remontan a marzo de este año), que ya ofrece buenas características, como una representación visual del estado actual del clúster y la gestión de sus objetos. Posicionado como una “interfaz en tiempo real”, porque actualiza automáticamente los datos mostrados sin necesidad de actualizar la página en el navegador.
2. Consola OpenShift - una interfaz web de Red Hat OpenShift, que, sin embargo, traerá a su clúster otros desarrollos del proyecto que no son adecuados para todos.
3. Kubernador es un proyecto interesante, creado como una interfaz de nivel inferior (que el Panel de control) con la capacidad de ver todos los objetos del clúster. Sin embargo, parece que su desarrollo se ha detenido.
4. Polaris - justo el otro día Anunciado un proyecto que combina las funciones de un panel (muestra el estado actual del clúster, pero no administra sus objetos) y una “validación de mejores prácticas” automática (verifica que el clúster verifique la exactitud de las configuraciones de las implementaciones que se ejecutan en él).

En lugar de conclusiones

Dashboard es una herramienta estándar para los clústeres de Kubernetes a los que servimos. Su integración con GitLab también se ha convertido en parte de nuestra instalación predeterminada, ya que muchos desarrolladores están entusiasmados con las capacidades que tienen con este panel.

Kubernetes Dashboard periódicamente tiene alternativas de la comunidad de código abierto (y estamos felices de considerarlas), pero en esta etapa nos quedamos con esta solución.

PS

Lea también en nuestro blog:

• «kubebox y otros shells para Kubernetes";
• «Mejores prácticas de CI/CD con Kubernetes y GitLab (revisión y reportaje en video)";
• «Cree e implemente aplicaciones en Kubernetes usando dapp y GitLab CI";
• «GitLab CI para integración y entrega continua en producción. Parte 1: nuestro oleoducto".

Fuente: habr.com