Kubernetes Dashboard e integración de GitLab

Kubernetes Dashboard es una herramienta fácil de usar para obtener información actualizada sobre un clúster en funcionamiento y un control mínimo sobre él. Usted comienza a apreciarlo aún más cuando el acceso a estas funciones es necesario no solo por los administradores / ingenieros de DevOps, sino también por aquellos que están menos acostumbrados a la consola y / o no tienen la intención de lidiar con todas las complejidades de interactuar con kubectl y otras utilidades. Así sucedió con nosotros: los desarrolladores querían un acceso rápido a la interfaz web de Kubernetes, y dado que usamos GitLab, la solución surgió de forma natural.

¿Por qué 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 hay otra forma, por ejemplo, a través de kubectl-debug ).

Además, hay un momento psicológico para los gerentes cuando quieren ver el clúster: ver que "todo es verde" y, por lo tanto, calmarse que "todo funciona" (que, por supuesto, es muy relativo ... pero esto está más allá del alcance del artículo )

Usamos GitLab como un sistema de CI estándar: todos los desarrolladores lo usan. Por lo tanto, para darles acceso, era lógico integrar Dashboard con cuentas en GitLab.

También tenga en cuenta que estamos utilizando NGINX Ingress. Si trabaja con otras soluciones de ingreso , necesitará encontrar análogos de anotaciones para autorización de forma independiente.

Intentamos la integración

Instalar el tablero de instrumentos

Atención : si va a repetir los pasos que se describen a continuación, para evitar operaciones innecesarias, primero lea el siguiente subtítulo.

Como utilizamos esta integración en muchas instalaciones, automatizamos su instalación. Las fuentes que se requieren para esto se publican en un repositorio especial de GitHub . Se basan en configuraciones YAML ligeramente modificadas del repositorio oficial de Dashboard , así como en un script Bash para una implementación rápida.

El script instala Dashboard en un clúster y lo configura para integrarse 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 kubernetes":



Como resultado de su incorporación, GitLab proporcionará hashes:



Se usan como argumentos para el guión. Como resultado, la instalación es la siguiente:

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

Después de eso, verifique que todo comenzó:

 $ 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 comenzará, ¡pero la autorización no funcionará de inmediato ! El hecho es que en la imagen utilizada (la situación en otras imágenes es similar), el proceso de captura de redireccionamiento en la devolución de llamada se implementa incorrectamente. Esta circunstancia lleva al hecho de que oauth borra la cookie, que en sí misma (oauth) nos proporciona ...

El problema se resuelve construyendo su propia imagen con el parche.

Parche para oauth y reinstalar

Para hacer esto, use 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 \ && go get -u github.com/golang/dep/cmd/dep \ && 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 fa2771998a98a5bfdfa3c3503757668ac4f1c8ec 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" ] 

Ahora puede construir la imagen e insertarla en nuestro GitLab. A continuación, en manifests/kube-dashboard-oauth2-proxy.yaml especifique el uso de la imagen deseada (reemplácela por la suya propia):

  image: docker.io/colemickens/oauth2_proxy:latest 

Si tiene un registro cerrado por autorización, no olvide agregar 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 

Un lector atento verá que la línea larga anterior es base64 de la configuración:

 {"registry.company.com": { "username": "oauth2", "password": "PASSWORD", "auth": "AUTH_TOKEN", "email": "mail@company.com" } } 

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

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

 $ ./ctl.sh -d 

... y reinstalar todo:

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

Es hora de entrar en el Tablero y encontrar el botón de inicio de sesión bastante arcaico:



Después de hacer clic en él, GitLab se reunirá con nosotros, ofreciéndole iniciar sesión en su página familiar (por supuesto, si no estuviéramos autorizados previamente allí):



Inicie sesión con sus credenciales de GitLab, y todo sucedió:

Acerca de las características del tablero

Si usted es un desarrollador que anteriormente no trabajaba con Kubernetes, o simplemente por alguna razón no se encontró con Dashboard antes, ilustraré algunas de sus características.

En primer lugar, puedes ver que "todo es verde":



Hay datos más detallados disponibles en los pods, como variables de entorno, imagen desinflada, argumentos de inicio, su estado:



Los estados de implementación son visibles:



... y otros detalles:



... así como la capacidad de escalar la implementación:



El resultado de esta operación:



Entre otras características útiles ya mencionadas al principio del artículo están los registros de visualización:



... y la función de ingresar a la consola del contenedor del pod seleccionado:



Por ejemplo, también puede ver el límite / solicitud en los nodos:



Por supuesto, estas no son todas las características del panel, pero espero que la idea general se haya desarrollado.

Desventajas de Integración y Tablero

En la integración descrita no hay control de acceso . Con él, todos los usuarios que tienen acceso a GitLab obtienen acceso al Tablero. Tienen el mismo acceso al Tablero, correspondiente a los derechos del Tablero mismo, que se definen en RBAC . Obviamente, esto no es adecuado para todos, pero para nuestro caso resultó ser suficiente.

De las desventajas notables en el Tablero, observo lo siguiente:

• es imposible ingresar a la consola del contenedor init;
• no es posible editar Deployments y StatefulSets, aunque esto se puede solucionar en ClusterRole;
• La compatibilidad del tablero con las últimas versiones de Kubernetes y el futuro del proyecto plantea preguntas.

El último problema merece especial atención.

Estado del tablero y alternativas

La tabla de compatibilidad de Dashboard con los lanzamientos de Kubernetes, presentada en la última versión del proyecto ( v1.10.1 ), no está muy contenta:



A pesar de esto, hay (ya adoptado en enero) PR # 3476 , que anuncia soporte para K8s 1.13. Además, entre los temas del proyecto puede encontrar referencias a usuarios que trabajan con el panel en K8s 1.14. Finalmente, los compromisos con la base del código del proyecto no se detienen. Entonces (¡al menos!) El estado real del proyecto no es tan malo como podría parecer en la tabla de compatibilidad oficial.

Finalmente, Dashboard tiene alternativas. Entre ellos están:

1. K8Dash es una interfaz joven (las primeras confirmaciones tienen fecha de marzo de este año), que ya ofrece buenas características, como una representación visual del estado actual del clúster y la administración de sus objetos. Se posiciona como una "interfaz en tiempo real", porque actualiza automáticamente los datos mostrados sin requerir una actualización de la página en el navegador.
2. OpenShift Console es una interfaz web de Red Hat OpenShift, que, sin embargo, traerá otros logros del proyecto a su clúster, que no se adapta a todos.
3. Kubernator es un proyecto interesante creado como una interfaz de nivel inferior (que el Tablero) con la capacidad de ver todos los objetos en el clúster. Sin embargo, todo parece que su desarrollo se ha detenido.
4. Polaris acaba de anunciar el otro día un proyecto que combina las funciones de un panel (muestra el estado actual del clúster, pero no administra sus objetos) y la "validación de mejores prácticas" automática (verifica en el clúster la configuración correcta de las implementaciones que se ejecutan en él).

En lugar de conclusiones

Dashboard es la herramienta estándar para los clústeres de Kubernetes 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 contentos con las oportunidades que tienen con este panel.

Kubernetes Dashboard periódicamente tiene alternativas de la comunidad Open Source (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 cascos de consola para Kubernetes ";
• " Mejores prácticas de CI / CD con Kubernetes y GitLab (revisión y video informe) ";
• " Crear e instalar aplicaciones en Kubernetes utilizando dapp y GitLab CI ";
• “ GitLab CI para la integración continua y la entrega en producción. Parte 1: nuestra tubería ".

UPD Según el informe de whoch, se encontró un error en el parche (las pestañas fueron reemplazadas por espacios). El parche en el artículo ha sido actualizado.