Tableau de bord Kubernetes et intégration GitLab

Kubernetes Dashboard est un outil facile à utiliser pour obtenir des informations à jour sur un cluster fonctionnel et un contrôle minimal sur celui-ci. Vous commencez à l'apprécier encore plus lorsque l'accès à ces fonctionnalités est nécessaire non seulement par les administrateurs / ingénieurs DevOps, mais aussi par 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. C'est ce qui nous est arrivé: les développeurs voulaient un accès rapide à l'interface Web de Kubernetes, et puisque nous utilisons GitLab, la solution est venue naturellement.

Pourquoi ça?

Les développeurs directs peuvent être intéressés par un outil comme K8s Dashboard pour les tâches de débogage. Parfois, vous souhaitez afficher les journaux et les ressources, et parfois tuer les pods, mettre à l'échelle les déploiements / StatefulSets et même aller dans la console du conteneur (il existe également des demandes pour lesquelles il existe une autre manière, par exemple, via kubectl-debug ).

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

Nous utilisons GitLab comme système CI standard: tous les développeurs l'utilisent. Par conséquent, pour leur donner accès, il était logique d'intégrer Dashboard avec des comptes dans GitLab.

Notez é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.

Nous essayons l'intégration

Installer le tableau de bord

Attention : Si vous allez répéter les étapes décrites ci-dessous, alors - afin d'é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 requises pour cela sont publiées dans un référentiel GitHub spécial . Ils sont basés sur des configurations YAML légèrement modifiées du référentiel officiel du tableau de bord , ainsi qu'un script Bash pour un déploiement rapide.

Le script installe Dashboard dans un cluster et le configure pour l'intégrer à 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 aller dans GitLab: zone Admin → Applications - et ajouter une nouvelle application pour le futur panneau. Appelons-le «tableau de bord kubernetes»:



À la suite de son ajout, GitLab fournira des hachages:



Ils sont utilisés comme arguments du script. En conséquence, l'installation est la suivante:

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

Après cela, vérifiez 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 

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

Le problème est résolu en créant votre image oauth avec le patch.

Correctif pour oauth et réinstallation

Pour ce faire, utilisez 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 \ && 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" ] 

Vous pouvez maintenant créer l'image et la pousser dans notre GitLab. Ensuite, dans manifests/kube-dashboard-oauth2-proxy.yaml spécifiez l'utilisation de l'image souhaitée (remplacez-la par la vôtre):

  image: docker.io/colemickens/oauth2_proxy:latest 

Si vous avez un registre fermé par autorisation - n'oubliez pas d'ajouter un secret pour extraire des 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 

Un lecteur attentif verra que la longue ligne ci-dessus est base64 de la config:

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

Il s'agit des données utilisateur dans GitLab, le code par lequel 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 dans le tableau de bord et de trouver le bouton de connexion plutôt archaïque:



Après avoir cliqué dessus, GitLab nous rencontrera, vous proposant de vous connecter sur sa page familière (bien sûr, si nous n'y étions pas préautorisés):



Connectez-vous avec vos informations d'identification GitLab - et tout s'est passé:

À propos des fonctionnalités du tableau de bord

Si vous êtes un développeur qui auparavant ne travaillait pas avec Kubernetes, ou tout simplement pour une raison quelconque, vous n'avez pas rencontré Dashboard auparavant, je vais illustrer certaines de ses fonctionnalités.

Tout d'abord, vous pouvez voir que "tout est vert":



Des données plus détaillées sont disponibles sur les pods, telles que les variables d'environnement, l'image dégonflée, les arguments de démarrage, leur état:



Les états de déploiement sont visibles:



... et autres détails:



... ainsi que la possibilité de dimensionner 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 figurent la visualisation des journaux:



... et la fonction d'entrer dans la console de conteneur du pod sélectionné:



Par exemple, vous pouvez également voir la limite / demande sur les nœuds:



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

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

Dans l'intégration décrite, il n'y a pas de contrôle d'accès . Avec lui, tous les utilisateurs qui ont un accès à GitLab ont accès au tableau de bord. Ils ont le même accès au tableau de bord, 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 pour notre cas, cela s'est avéré suffisant.

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

• il est impossible d'accéder à la console du conteneur init;
• il n'est pas possible de modifier les déploiements et les StatefulSets, bien que cela puisse être résolu dans ClusterRole;
• La compatibilité du tableau de bord avec les dernières versions de Kubernetes et l'avenir du projet soulève des questions.

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

État du tableau de bord et alternatives

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



Malgré cela, il existe (déjà adopté en janvier) le PR # 3476 , qui annonce la prise en charge des K8 1.13. De plus, parmi les problèmes du projet, vous pouvez trouver des références aux utilisateurs travaillant avec le panneau dans K8s 1.14. Enfin, les validations sur la base de code du projet ne s'arrêtent pas. Donc (au moins!) Le statut réel du projet n'est pas aussi mauvais qu'il pourrait d'abord apparaître dans le tableau de compatibilité officiel.

Enfin, Dashboard a des alternatives. Parmi eux:

1. K8Dash est une interface jeune (les premiers commits sont datés 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. Il se positionne comme une «interface en temps réel», car met à jour automatiquement les données affichées sans nécessiter une actualisation de page dans le navigateur.
2. OpenShift Console est une interface Web de Red Hat OpenShift, qui, cependant, apportera d'autres réalisations de projet à votre cluster, ce qui ne convient pas à tout le monde.
3. Kubernator est un projet intéressant créé en tant qu'interface de niveau inférieur (que Dashboard) avec la possibilité de visualiser tous les objets du cluster. Cependant, tout semble avoir cessé son développement.
4. Polaris vient d' annoncer un projet combinant les fonctions d'un panneau (affiche l'état actuel du cluster, mais ne gère pas ses objets) et la validation automatique des meilleures pratiques (vérifie la configuration correcte des déploiements qui y sont exécutés).

Au lieu de conclusions

Dashboard est l'outil standard pour les clusters Kubernetes que nous desservons. Son intégration avec GitLab fait également partie de notre «installation par défaut», car de nombreux développeurs sont satisfaits des opportunités qu'ils ont avec ce panneau.

Kubernetes Dashboard a 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

Lisez aussi dans notre blog:

• « Kubebox et autres coques de console pour Kubernetes »;
• « Meilleures pratiques CI / CD avec Kubernetes et GitLab (revue et rapport vidéo) »;
• « Créer et installer 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 . "

UPD Selon le rapport whoch, une erreur a été trouvée dans le patch (les tabulations ont été remplacées par des espaces). Le correctif de l'article a été mis à jour.