Kubernetes Dashboard es una herramienta fácil de usar para obtener información actual sobre un clúster en funcionamiento y una gestión mínima de este. Se empieza a apreciar aún más cuando el acceso a estas funciones no solo es necesario para administradores/ingenieros de DevOps, sino también para quienes están menos acostumbrados a la consola y/o no tienen intención de profundizar en todos los matices de la interacción con kubectl y otras utilidades. Eso nos sucedió a nosotros: los desarrolladores querían un acceso rápido a la interfaz web de Kubernetes, y dado que usamos GitLab, la solución se presentó por sí sola.
¿Por qué es esto?
Los desarrolladores directos pueden estar interesados en una herramienta como el K8s Dashboard para tareas de depuración. A veces se desea revisar registros y recursos, y otras veces matar pods, escalar Deployments/StatefulSets e incluso acceder a la consola de contenedores (hay solicitudes para esto, para las cuales, sin embargo, hay otro camino — por ejemplo, a través de ).
Además, hay un aspecto psicológico para los líderes, cuando quieren echar un vistazo al clúster — ver que 'todo está en verde' y así sentirse tranquilos de que 'todo funciona' (lo cual, por supuesto, es bastante relativo… pero eso ya escapa al alcance de este artículo).
Como sistema CI estándar, tenemos GitLab: lo utilizan todos los desarrolladores. Por lo tanto, para proporcionarles acceso, era lógico integrar el Dashboard con las cuentas de GitLab.
También señalaré que usamos NGINX Ingress. Si trabajas con otros , necesitarás encontrar por tu cuenta análogos de anotaciones para la autorización.
Probando la integración
Instalación del Dashboard
Atención: Si vas a repetir los pasos descritos a continuación, primero léelos hasta el siguiente subtítulo para evitar operaciones innecesarias.
Dado que esta integración se utiliza en numerosas instalaciones, hemos automatizado su instalación. Los fuentes que necesitarás para esto están publicados en . Se basan en configuraciones YAML ligeramente modificadas del , así como en un script de Bash para un despliegue rápido.
El script instala el Dashboard en el clúster y lo configura para su integración con GitLab:
$ .\/ctl.sh
Uso: ctl.sh [OPCIÓN]... --gitlab-url GITLAB_URL --oauth2-id ID --oauth2-secret SECRET --dashboard-url DASHBOARD_URL
Instalar kubernetes-dashboard en el clúster de Kubernetes.
Argumentos obligatorios:
-i, --install instalar en el namespace 'kube-system'
-u, --upgrade actualizar la instalación existente, reutilizará la contraseña y los nombres de host
-d, --delete eliminar todo, incluido el namespace
--gitlab-url establecer la URL de gitlab con esquema (https://gitlab.example.com)
--oauth2-id establecer OAUTH2_PROXY_CLIENT_ID de gitlab
--oauth2-secret establecer OAUTH2_PROXY_CLIENT_SECRET de gitlab
--dashboard-url establecer la URL del dashboard sin esquema (dashboard.example.com)
Argumentos opcionales:
-h, --help mostrar este mensajeSin embargo, antes de usarlo, es necesario ingresar a GitLab: Área de administración → Aplicaciones — y agregar una nueva aplicación para el futuro panel. Llamémosla «kubernetes dashboard»:
Como resultado de su adición, GitLab proporcionará los hashes:
Estos son utilizados como argumentos para el script. Como resultado, la instalación se ve de la siguiente manera:
$ .\/ctl.sh -i --gitlab-url https://gitlab.example.com --oauth2-id 6a52769e… --oauth2-secret 6b79168f… --dashboard-url dashboard.example.comDespués de esto, verifiquemos que todo se haya iniciado:
$ kubectl -n kube-system get pod | egrep '(dash|oauth)'
kubernetes-dashboard-76b55bc9f8-xpncp 1\/1 Ejecutándose 0 14s
oauth2-proxy-5586ccf95c-czp2v 1\/1 Ejecutándose 0 14sTarde o temprano todo se iniciará, sin embargo la autorización no funcionará de inmediato! La cuestión es que en la imagen utilizada (la situación es similar en otras imágenes) el proceso de captura de redirección en el callback está implementado incorrectamente. Esto provoca que oauth borre la cookie que él mismo (oauth) nos proporciona...
El problema se soluciona construyendo su propia imagen oauth con un parche.
Parche para oauth y reinstalación
Para esto, 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" ]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 "... ejecutando pruebas"
-.\/test.sh
+#.\/test.sh
-para os en windows linux darwin; hacer
- echo "... construyendo v$version para $os/$arch"
- EXT=
- si [ $os = windows ]; entonces
- 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
-hecho
+os='linux'
+echo "... construyendo v$version para $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 podemos construir la imagen y hacer 'push' a nuestro propio GitLab. A continuación, en manifests/kube-dashboard-oauth2-proxy.yaml indicaremos el uso de la imagen necesaria (reemplácela por la suya):
image: docker.io/colemickens/oauth2_proxy:latestSi tiene un registro protegido por autorización, no olvide agregar el uso de un secreto para obtener la imagen:
imagePullSecrets:
- name: gitlab-registry… y agregue el propio secreto para el registro:
---
apiVersion: v1
data:
.dockercfg: eyJyZWdpc3RyeS5jb21wYW55LmNvbSI6IHsKICJ1c2VybmFtZSI6ICJvYXV0aDIiLAogInBhc3N3b3JkIjogIlBBU1NXT1JEIiwKICJhdXRoIjogIkFVVEhfVE9LRU4iLAogImVtYWlsIjogIm1haWxAY29tcGFueS5jb20iCn0KfQoK
=
kind: Secret
metadata:
annotations:
name: gitlab-registry
namespace: kube-system
type: kubernetes.io/dockercfgUn lector atento verá que la larga cadena anterior es la 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, que Kubernetes usará para obtener la imagen del registro.
Una vez que todo esté listo, se puede eliminar la instalación actual (no funcional) del Dashboard 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.comEs hora de ingresar al Dashboard y encontrar el bastante arcaico botón de autorización:
Al hacer clic en él, nos encontrará GitLab, ofreciéndonos autenticarnos en su habitual página (por supuesto, si no hemos sido autenticados previamente allí):
Iniciamos sesión con nuestras credenciales de GitLab — y todo se ha logrado:
Sobre las capacidades del Dashboard
Si eres un desarrollador que nunca ha trabajado con Kubernetes, o por alguna razón nunca te has encontrado con el Dashboard, ilustraré algunas de sus capacidades.
En primer lugar, se puede ver que "todo está en verde":
Para los pods, hay datos más detallados, como las variables de entorno, la imagen descargada, los argumentos de inicio y su estado:
Los deployments muestran sus estados:
… y otros detalles:
… así como la posibilidad de escalar el deployment:
El resultado de esta operación:
Entre otras útiles características, ya mencionadas al principio del artículo, está la visualización de logs:
… y la función de acceder a la consola de los contenedores del pod seleccionado:
Además, se pueden ver también los límites/solicitudes en los nodos:
Por supuesto, no son todas las funciones del panel, pero espero que se haya formado una idea general.
Desventajas de la integración y Dashboard
En la integración descrita no hay ningún control de acceso. Todos los usuarios que tienen algún acceso a GitLab obtienen acceso al Dashboard. El acceso en el propio Dashboard es el mismo, correspondiente a los derechos del propio Dashboard, que . Es evidente que esto no será adecuado para todos, pero para nuestro caso resultó suficiente.
Entre las desventajas notables del propio panel Dashboard, señalaré las siguientes:
- no se puede acceder a la consola del contenedor init;
- no se pueden editar Deployments y StatefulSets, aunque esto se puede corregir en ClusterRole;
- la compatibilidad del Dashboard con las últimas versiones de Kubernetes y el futuro del proyecto generan dudas.
El último problema merece atención especial.
Estado y alternativas del Dashboard
La tabla de compatibilidad del Dashboard con las versiones de Kubernetes, presentada en la última versión del proyecto (), no es muy alentadora:
A pesar de esto, existe (ya aceptado en enero) , que anuncia soporte para K8s 1.13. Además, entre los problemas del proyecto se pueden encontrar menciones de usuarios que trabajan con el panel en K8s 1.14. Finalmente, en la base de código del proyecto no cesan. Así que (¡al menos!) el estado real del proyecto no es tan malo como podría parecer inicialmente según la tabla oficial de compatibilidad.
Por último, el Dashboard tiene alternativas. Entre ellas:
- — una interfaz nueva (los primeros commits datan de marzo de este año), que ya ofrece buenas funcionalidades, como la visualización del estado actual del clúster y la gestión de sus objetos. Se posiciona como una «interfaz en tiempo real», ya que actualiza automáticamente los datos mostrados sin necesidad de refrescar la página en el navegador.
- — una interfaz web de Red Hat OpenShift, que, sin embargo, traería a su clúster otras contribuciones del proyecto, lo cual no es adecuado para todos.
- — un proyecto interesante, creado como una interfaz de nivel más bajo (que el Dashboard) con la posibilidad de ver todos los objetos del clúster. Sin embargo, parece que su desarrollo ha cesado.
- — literalmente hace unos días un proyecto que combina funciones de un panel (muestra el estado actual del clúster, pero no gestiona sus objetos) y una «validación automática de mejores prácticas» (verifica la validez de las configuraciones de los Deployments que se han lanzado en él).
En lugar de conclusiones
Dashboard — una herramienta estándar para clústeres de Kubernetes que administramos. Su integración con GitLab también se ha convertido en parte de nuestra «instalación por defecto», ya que muchos desarrolladores están contentos con las oportunidades que les ofrece este panel.
El Kubernetes Dashboard periódicamente recibe alternativas de la comunidad de Open Source (y estamos encantados de considerarlas), sin embargo, en este momento seguimos con esta solución.
P.D.
También puedes leer en nuestro blog:
- «»;
- «»;
- «»;
- «».
Fuente: habr.com
