Intégration du tableau de bord Kubernetes et des utilisateurs GitLab

Kubernetes Dashboard est un outil facile à utiliser pour obtenir des informations à jour sur votre cluster en cours d'exécution et le gérer avec un minimum d'effort. Vous commencez à l'apprécier encore plus lorsque l'accès à ces fonctionnalités est nécessaire non seulement aux administrateurs/ingénieurs DevOps, mais aussi à ceux qui sont moins habitués à la console et/ou n'ont pas l'intention de gérer toutes les subtilités de l'interaction avec kubectl et d'autres utilitaires. Cela s'est produit chez nous : les développeurs souhaitaient un accès rapide à l'interface web de Kubernetes, et comme nous utilisons GitLab, la solution est venue naturellement.

Pourquoi est-ce

Les développeurs directs peuvent être intéressés par un outil tel que K8s Dashboard pour les tâches de débogage. Parfois, vous souhaitez afficher les journaux et les ressources, et parfois supprimer des pods, mettre à l'échelle des déploiements/StatefulSets et même accéder à la console du conteneur (il existe également des requêtes pour lesquelles, cependant, il existe un autre moyen - par exemple, via Kubectl-débogage).

De plus, il y a un moment psychologique pour les managers où ils veulent regarder le cluster : voir que « tout est vert », et ainsi se rassurer que « tout fonctionne » (ce qui, bien sûr, est très relatif... mais cela dépasse le cadre de l'article).

En tant que système CI standard, nous avons applique GitLab : tous les développeurs l'utilisent aussi. Par conséquent, pour leur fournir un accès, il était logique d'intégrer Dashboard aux comptes GitLab.

Je noterai également que nous utilisons NGINX Ingress. Si vous travaillez avec d'autres solutions d'entrée, vous devrez trouver indépendamment des analogues d'annotations pour l'autorisation.

Essayer l'intégration

Installation du tableau de bord

prudence: Si vous souhaitez répéter les étapes ci-dessous, alors - pour éviter des opérations inutiles - lisez d'abord le sous-titre suivant.

Puisque nous utilisons cette intégration dans de nombreuses installations, nous avons automatisé son installation. Les sources nécessaires à cela sont publiées dans dépôt GitHub spécial. Ils sont basés sur des configurations YAML légèrement modifiées de référentiel officiel du tableau de bord, ainsi qu'un script Bash pour un déploiement rapide.

Le script installe Dashboard dans le cluster et le configure pour l'intégration avec 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

Cependant, avant de l'utiliser, vous devez vous rendre sur GitLab : Zone d'administration → Applications - et ajouter une nouvelle application pour le futur panel. Appelons-le « tableau de bord Kubernetes » :

Suite à son ajout, GitLab fournira les hachages :

Ce sont eux qui servent d’arguments au script. En conséquence, l'installation ressemble à ceci :

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

Après cela, vérifions que tout a commencé :

$ 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

Mais tôt ou tard, tout commencera l'autorisation ne fonctionnera pas immédiatement! Le fait est que dans l'image utilisée (la situation dans d'autres images est similaire), le processus de capture d'une redirection dans le rappel est mal implémenté. Cette circonstance conduit au fait qu'oauth efface le cookie qu'oauth lui-même nous fournit...

Le problème est résolu en créant votre propre image oauth avec un correctif.

Corrigez oauth et réinstallez

Pour ce faire, nous utiliserons le Dockerfile suivant :

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" ]

Et voici à quoi ressemble le patch rd.patch lui-même

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

Vous pouvez maintenant créer l’image et la transférer dans notre GitLab. Suivant dans manifests/kube-dashboard-oauth2-proxy.yaml indiquez l'utilisation de l'image souhaitée (remplacez-la par la vôtre) :

 image: docker.io/colemickens/oauth2_proxy:latest

Si vous disposez d'un registre fermé par autorisation, n'oubliez pas d'ajouter l'utilisation d'un secret pour les pull images :

      imagePullSecrets:
     - name: gitlab-registry

... et ajoutez le secret lui-même pour le registre :

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

Le lecteur attentif verra que la longue chaîne ci-dessus est en base64 de la configuration :

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

Il s'agit des données utilisateur dans GitLab, le code Kubernetes extraira l'image du registre.

Une fois que tout est terminé, vous pouvez supprimer l'installation actuelle (qui ne fonctionne pas correctement) du tableau de bord avec la commande :

$ ./ctl.sh -d

... et réinstallez tout :

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

Il est temps d'aller sur le Dashboard et de trouver un bouton de connexion plutôt archaïque :

Après avoir cliqué dessus, GitLab nous accueillera en nous proposant de nous connecter à sa page habituelle (bien sûr, si nous n'y sommes pas déjà connectés) :

Nous nous connectons avec les informations d'identification GitLab - et tout est fait :

À propos des fonctionnalités du tableau de bord

Si vous êtes un développeur qui n'a jamais travaillé avec Kubernetes auparavant, ou si, pour une raison quelconque, vous n'avez jamais rencontré Dashboard auparavant, je vais illustrer certaines de ses fonctionnalités.

Tout d’abord, vous pouvez constater que « tout est vert » :

Des données plus détaillées sont également disponibles pour les pods, telles que les variables d'environnement, l'image téléchargée, les arguments de lancement et leur état :

Les déploiements ont des statuts visibles :

...et d'autres détails :

... et il y a aussi la possibilité d'adapter le déploiement :

Le résultat de cette opération :

Parmi les autres fonctionnalités utiles déjà mentionnées au début de l'article, citons l'affichage des journaux :

... et la fonction pour se connecter à la console du conteneur du pod sélectionné :

Par exemple, vous pouvez également consulter les limites/requêtes sur les nœuds :

Bien sûr, ce ne sont pas toutes les capacités du panneau, mais j'espère que vous comprenez l'idée générale.

Inconvénients de l'intégration et du tableau de bord

Dans l'intégration décrite, il n'y a pas contrôle d'accès. Grâce à lui, tous les utilisateurs ayant accès à GitLab ont accès au tableau de bord. Ils disposent du même accès dans le Tableau de bord lui-même, correspondant aux droits du Tableau de bord lui-même, qui sont définis dans RBAC. Évidemment, cela ne convient pas à tout le monde, mais dans notre cas, cela s'est avéré suffisant.

Parmi les inconvénients notables du tableau de bord lui-même, je note les suivants :

• il est impossible d'accéder à la console du conteneur d'initialisation ;
• il est impossible de modifier les déploiements et les StatefulSets, bien que cela puisse être corrigé dans ClusterRole ;
• La compatibilité de Dashboard avec les dernières versions de Kubernetes et l'avenir du projet soulèvent des questions.

Le dernier problème mérite une attention particulière.

État du tableau de bord et alternatives

Tableau de compatibilité du tableau de bord avec les versions de Kubernetes, présenté dans la dernière version du projet (v1.10.1), pas très content :

Malgré cela, il existe (déjà adopté en janvier) RP #3476, qui annonce le support de K8s 1.13. De plus, parmi les problèmes du projet, vous pouvez trouver des références à des utilisateurs travaillant avec le panneau dans K8s 1.14. Enfin, commet dans la base de code du projet ne vous arrêtez pas. Donc (au moins !) l’état actuel du projet n’est pas aussi mauvais qu’il y paraît à première vue d’après le tableau de compatibilité officiel.

Enfin, il existe des alternatives au Dashboard. Parmi eux:

1. K8Dash — une interface jeune (les premiers commits datent de mars de cette année), qui offre déjà de bonnes fonctionnalités, comme une représentation visuelle de l'état actuel du cluster et la gestion de ses objets. Positionné comme une « interface temps réel », car met automatiquement à jour les données affichées sans que vous ayez à actualiser la page dans le navigateur.
2. Console OpenShift - une interface web de Red Hat OpenShift, qui amènera cependant d'autres développements du projet dans votre cluster, ce qui ne convient pas à tout le monde.
3. Kubernateur est un projet intéressant, créé comme une interface de niveau inférieur (que Dashboard) avec la possibilité de visualiser tous les objets du cluster. Cependant, il semble que son développement se soit arrêté.
4. Polaris - juste l'autre jour annoncé un projet qui combine les fonctions d'un panneau (affiche l'état actuel du cluster, mais ne gère pas ses objets) et de « validation automatique des meilleures pratiques » (vérifie le cluster pour l'exactitude des configurations des déploiements qui y sont exécutés).

Au lieu de conclusions

Dashboard est un outil standard pour les clusters Kubernetes que nous servons. Son intégration avec GitLab fait également partie de notre installation par défaut, car de nombreux développeurs sont enthousiasmés par les capacités dont ils disposent avec ce panneau.

Kubernetes Dashboard propose périodiquement des alternatives de la communauté Open Source (et nous sommes heureux de les considérer), mais à ce stade, nous restons avec cette solution.

PS

A lire aussi sur notre blog :

• «kubebox et autres shells pour Kubernetes";
• «Meilleures pratiques CI/CD avec Kubernetes et GitLab (revue et rapport vidéo)";
• «Créez et déployez des applications dans Kubernetes à l'aide de dapp et GitLab CI";
• «GitLab CI pour une intégration et une livraison continues en production. Partie 1 : notre pipeline».

Source: habr.com