Le Kubernetes Dashboard est un outil simple à utiliser pour obtenir des informations à jour sur un cluster en fonctionnement et en effectuer une gestion minimale. On finit par l'apprécier d'autant plus lorsque l'accès à ces fonctionnalités est nécessaire non seulement pour les administrateurs ou les ingénieurs DevOps, mais aussi pour ceux qui sont moins familiers avec la console et/ou qui ne souhaitent pas s'immerger dans toutes les subtilités de l'interaction avec kubectl et d'autres utilitaires. C'est exactement ce qui s'est passé pour nous : les développeurs ont souhaité un accès rapide à l'interface web de Kubernetes, et comme nous utilisons GitLab, la solution s'est imposée d'elle-même.
Pourquoi faire cela ?
Les développeurs peuvent être intéressés par un outil comme le Kubernetes Dashboard pour des tâches de débogage. Parfois, ils veulent consulter des journaux et des ressources, et parfois, ils souhaitent même arrêter des pod, mettre à l'échelle des Deployments/StatefulSets et même accéder à la console des conteneurs (ce qui arrive et pour résoudre ces demandes, il existe d'autres moyens, par exemple par ).
De plus, il y a un aspect psychologique pour les responsables, qui souhaitent jeter un œil au cluster — voir que 'tout est vert' et ainsi se rassurer que 'tout fonctionne' (ce qui, bien sûr, est très relatif... mais cela sort du cadre de cet article).
Comme système CI standard, nous GitLab : tous les développeurs l'utilisent. Donc, pour leur donner accès, il était logique d'intégrer le Dashboard avec les comptes GitLab.
Je note également que nous utilisons NGINX Ingress. Si vous travaillez avec d'autres , vous devrez trouver vous-même des équivalents pour les annotations d'autorisation.
Testons l'intégration
Installation du Dashboard
Attention: Si vous prévoyez de répéter les étapes décrites ci-dessous, veuillez d'abord lire jusqu'à la sous-section suivante pour éviter des opérations superflues.
Étant donné que cette intégration est utilisée par nous dans de nombreuses installations, nous avons automatisé son installation. Les sources nécessaires à cela sont publiées dans . Elles reposent sur des configurations YAML légèrement modifiées issues de , ainsi qu'un script Bash pour un déploiement rapide.
Le script installe le 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
Installe le kubernetes-dashboard sur le cluster Kubernetes.
Arguments obligatoires:
-i, --install installe dans l'espace de noms 'kube-system'
-u, --upgrade met à niveau l'installation existante, réutilisera les mots de passe et les noms d'hôte
-d, --delete supprime tout, y compris l'espace de noms
--gitlab-url définit l'url gitlab avec schéma (https://gitlab.example.com)
--oauth2-id définit OAUTH2_PROXY_CLIENT_ID depuis gitlab
--oauth2-secret définit OAUTH2_PROXY_CLIENT_SECRET depuis gitlab
--dashboard-url définit l'url du tableau de bord sans schéma (dashboard.example.com)
Arguments optionnels:
-h, --help affiche ce messageCependant, avant de l'utiliser, il est nécessaire de se rendre sur GitLab : zone d'administration → Applications — et d'ajouter une nouvelle application pour le tableau de bord futur. Appelons-la « kubernetes dashboard » :
En conséquence de son ajout, GitLab fournira des clés :
Celles-ci sont utilisées comme arguments pour le script. En conséquence, l'installation apparaît comme suit :
$ .\/ctl.sh -i --gitlab-url https://gitlab.example.com --oauth2-id 6a52769e… --oauth2-secret 6b79168f… --dashboard-url dashboard.example.comAprès cela, vérifions que tout a démarré :
$ kubectl -n kube-system get pod | egrep '(dash|oauth)'
kubernetes-dashboard-76b55bc9f8-xpncp 1\/1 En cours d'exécution 0 14s
oauth2-proxy-5586ccf95c-czp2v 1\/1 En cours d'exécution 0 14sTôt ou tard, tout sera lancé, cependant l'authentification ne fonctionnera pas immédiatement! Le problème est que l'image utilisée (la situation dans d'autres images est similaire) a mal implémenté le processus de capture de la redirection dans le callback. Cela entraîne le fait que oauth supprime le cookie, que lui-même (oauth) nous fournit…
Le problème se résout en construisant sa propre image oauth avec le patch.
Patch pour oauth et réinstallation
Pour cela, 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 [ \Voici à quoi ressemble le patch 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 "... exécution des tests"
-. /test.sh
+#. /test.sh
-for os in windows linux darwin; do
- echo "... construction de v$version pour $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 "... construction de v$version pour $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 Il est maintenant possible de construire l'image et de la pousser dans notre GitLab. Ensuite, dans manifests/kube-dashboard-oauth2-proxy.yaml nous allons spécifier l'utilisation de l'image nécessaire (remplacez-la par la vôtre) :
image: docker.io/colemickens/oauth2_proxy:latestSi vous avez un registre protégé par authentification, n'oubliez pas d'ajouter l'utilisation du secret pour tirer les 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/dockercfgL lecteur attentif remarquera que la longue chaîne ci-dessus est un base64 du config :
{"registry.company.com": {
"username": "oauth2",
"password": "PASSWORD",
"auth": "AUTH_TOKEN",
"email": "mail@company.com"
}
}Ce sont les données de l'utilisateur dans GitLab, que Kubernetes utilisera pour tirer l'image du registre.
Après avoir tout fait, vous pouvez supprimer l'installation actuelle (qui ne fonctionne pas correctement) du Dashboard avec la commande :
$ ./ctl.sh -d… et tout réinstaller :
$ .\/ctl.sh -i --gitlab-url https://gitlab.example.com --oauth2-id 6a52769e… --oauth2-secret 6b79168f… --dashboard-url dashboard.example.comIl est temps d'entrer dans le Dashboard et de trouver ce bouton d'authentification quelque peu archaïque :
Après avoir cliqué dessus, nous serons accueillis par GitLab, nous proposant de nous authentifier sur notre page habituelle (bien sûr, si nous n'avons pas été préalablement authentifiés là-bas) :
Nous nous authentifions avec nos identifiants GitLab — et tout est accompli :
Les fonctionnalités du Dashboard
Si vous êtes développeur et que vous n'avez jamais travaillé avec Kubernetes, ou simplement pour une raison quelconque vous n'avez pas encore rencontré le Dashboard, je vais illustrer certaines de ses fonctionnalités.
Tout d'abord, vous pouvez voir que « tout est en vert » :
Pour les pods, des données plus détaillées sont disponibles, telles que les variables d'environnement, l'image récupérée, les arguments de lancement, leur état :
Pour les déploiements, les statuts sont visibles :
… et d'autres détails :
… ainsi qu'une possibilité de redimensionner le déploiement :
Le résultat de cette opération :
Parmi d'autres fonctionnalités utiles, déjà mentionnées au début de l'article, il y a la visualisation des logs :
… et la fonction d'accès à la console des conteneurs du pod sélectionné :
Il est aussi possible de consulter les limites/ressources sur les nœuds :
Bien sûr, ce n'est pas toutes les fonctionnalités du panel, mais j'espère que cela donne une idée générale.
Inconvénients de l'intégration et du Dashboard
Dans l'intégration décrite, il n'y a pas de séparation des accès. Tous les utilisateurs ayant accès à GitLab ont accès au Dashboard. Leur accès dans le Dashboard est identique, correspondant aux droits du Dashboard lui-même, qui . Cela ne conviendra pas à tout le monde, mais pour notre cas, cela s'est avéré suffisant.
Parmi les inconvénients notables du Dashboard, je souligne les suivants :
- impossibilité d'accéder à la console du conteneur init ;
- impossibilité d'éditer les Deployments et StatefulSets, même si cela peut être corrigé dans ClusterRole ;
- la compatibilité du Dashboard avec les dernières versions de Kubernetes et l'avenir du projet soulèvent des questions.
Ce dernier problème mérite une attention particulière.
Statut et alternatives du Dashboard
Le tableau de compatibilité du Dashboard avec les versions de Kubernetes, présenté dans la dernière version du projet (), n'est pas très engageant :
Malgré cela, il existe (déjà accepté en janvier) , qui annonce le support de K8s 1.13. De plus, parmi les problèmes du projet, on peut trouver des mentions d'utilisateurs travaillant avec le panel dans K8s 1.14. Enfin, dans la base de code du projet ne cessent pas. Ainsi, (au moins !) l'état réel du projet n'est pas aussi mauvais qu'il peut d'abord sembler d'après le tableau de compatibilité officiel.
Enfin, il existe des alternatives au Dashboard. Parmi elles :
- — une interface jeune (les premiers commits datent de mars de cette année), déjà offrant de bonnes possibilités, telles qu'une représentation visuelle de l'état actuel du cluster et la gestion de ses objets. Elle se positionne comme une « interface en temps réel », car elle actualise automatiquement les données affichées sans nécessiter de recharger la page dans le navigateur.
- — une interface web de Red Hat OpenShift, qui apportera cependant dans votre cluster d'autres développements du projet, ce qui ne convient pas à tout le monde.
- — un projet intéressant, créé comme une interface de niveau inférieur (par rapport au Dashboard) permettant de visualiser tous les objets du cluster. Cependant, il semble que son développement ait été arrêté.
- — littéralement il y a quelques jours projet, qui combine des fonctions de tableau de bord (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 Deployments qui y sont lancés).
Au lieu des conclusions
Le Dashboard est l'outil standard pour les clusters Kubernetes que nous gérons. Son intégration avec GitLab fait également partie de notre « installation par défaut », car de nombreux développeurs apprécient les possibilités qu'ils obtiennent avec ce tableau de bord.
Des alternatives au Kubernetes Dashboard apparaissent périodiquement dans la communauté Open Source (et nous sommes heureux de les examiner), toutefois à ce stade, nous restons avec cette solution.
P.S.
Lisez aussi dans notre blog :
- «»;
- «»;
- «»;
- «».
Source : habr.com
