En lisant des documents sur Kubernetes, vous avez probablement rencontré à plusieurs reprises des exemples de diverses commandes kubectl et des configurations YAML délicates. Pour les personnes qui connaissent bien les K8, cette approche ne provoque sans aucun doute aucun rejet. Mais à l'ère de l'ubiquité des interfaces Web, il ne peut pas être qualifié de convivial pour les utilisateurs ordinaires. Cela complique le processus d'apprentissage pour les débutants et agit comme un obstacle pour ceux qui ne sont pas très familiers avec Kubernetes.
Bien sûr, il existe différentes interfaces graphiques pour K8, y compris le tableau de bord Kubernetes , qui fait partie de Kubernetes en amont lui-même. (Note de traduction: nous avons déjà parlé de nombreuses solutions existantes dans cette comparaison .) Cependant, en explorant toute la variété des options, nous n'avons pas pu trouver une solution qui nous conviendrait parfaitement. Je voulais l'interface:
- était 100% Open Source;
- activement soutenu par la communauté;
- était universel en ce sens qu'il n'était pas lié à la distribution Kubernetes d'un fournisseur particulier;
- était modulaire et extensible;
- avait une apparence soignée et moderne;
- a été implémenté sur une pile familière à nos développeurs (Go, JavaScript / TypeScript, React);
- était interactif (c'est-à-dire non seulement collecté des données, mais aussi permis certaines actions avec le cluster);
- pris en charge le mode multi-cluster.
Malgré le choix plutôt riche, aucune des solutions que nous avons testées ne répondait à tous les critères énumérés ci-dessus (ou pourrait servir de bonne base pour créer une nouvelle solution). Par conséquent, selon une tradition séculaire, nous avons décidé de le fabriquer nous-mêmes ...
Présentation de la lampe frontale
Aujourd'hui, je suis fier d'annoncer la grande disponibilité d'une nouvelle interface utilisateur pour Kubernetes appelé Headlamp .
Headlamp est une interface utilisateur Kubernetes polyvalente et extensible qui répond aux critères ci-dessus. Bien sûr, étant l'idée originale de Kinvolk, il est 100% Open Source. Nous espérons que de nombreux membres de la communauté Kubernetes apprécieront non seulement Headlamp, mais contribueront également au projet.
Jetons un coup d'œil à ses principales caractéristiques.
Interface utilisateur extensible
Nous nous efforçons de faire en sorte que Headlamp soit adapté à autant de cas d'utilisation que possible. Le public cible du projet n'est pas seulement les nouveaux venus sur Kubernetes, mais aussi les administrateurs expérimentés et les fournisseurs de K8 avec des besoins très différents. Souvent (en particulier pour les projets d'interface utilisateur), une telle variété de cas d'utilisation est mise en œuvre en créant un grand nombre de fourches, chacune étant gérée par sa propre équipe en aval. Mais il est plus difficile de garder les fourches à jour à mesure que les changements sont importants.
Le système de plugins résout ce problème. C'est pourquoi Headlamp prend en charge les plugins d'interface utilisateur hors de l'arborescence. Ce sont des fichiers JavaScript qui sont chargés par le backend Headlamp et transmis au client, qui les charge dynamiquement.
Cette approche ouvre de grandes opportunités d'innovation, contribuant à l'émergence de nombreuses nouvelles fonctionnalités. Par exemple, il est facile de créer un bouton dans le bloc de détails du pod qui redirigera l'utilisateur vers un service indiquant le coût financier de ce pod.
Le mécanisme du plugin Headlamp ouvre de grandes opportunités pour la communauté. Et nous sommes prêts à coopérer avec tous ceux qui souhaitent participer au développement de nouveaux plugins pour Headlamp, et à développer le mécanisme lui-même, en l'adaptant à de nouveaux scénarios d'utilisation.
Traceloop
Pour démontrer toute la puissance du mécanisme du plugin (et l'outil lui-même), nous avons développé un plugin Headlamp pour le gadget traceloop , qui fait partie du projet Inspektor Gadget (un ensemble d'outils pour inspecter et déboguer des applications dans Kubernetes - environ Transl.) .
Après avoir installé le gadget Inspektor et activé le gadget traceloop, il commence à écrire tous les appels système du pod dans un tampon circulaire. Ce tampon peut être visualisé en temps réel pendant le fonctionnement du pod. En d'autres termes, traceloop vous donne un aperçu de ce que fait le pod en ce moment. De plus, les données de la mémoire tampon sont enregistrées pour les pods qui sont sortis. De cette façon, vous pouvez déterminer la cause de l'échec une fois qu'il s'est produit - une sorte de «boîte noire» pour les applications Kubernetes.
Interface utilisateur sélective
Le problème avec de nombreuses interfaces utilisateur CRUD est qu'elles ne savent rien de l'organisation interne du contrôle d'accès. Par exemple, la présence de boutons d'édition / suppression induit l'utilisateur en erreur s'il n'a pas réellement l'autorisation de modifier la ressource. Headlamp vérifie les paramètres RBAC de Kubernetes et n'affiche que les commandes des actions disponibles pour l'utilisateur. Par exemple, si l'utilisateur n'a pas le droit de modifier la ressource, le bouton «modifier» ne sera pas affiché.
Tout cela a un effet extrêmement bénéfique sur l'expérience utilisateur: après tout, l'opérateur voit immédiatement quelles actions sont à sa disposition, en tenant compte des droits actuels. Ceci est idéal pour les situations où des autorisations limitées dans le temps sont accordées (telles que l'autorisation temporaire de supprimer une ressource).
Boutons disponibles pour les actions avec le module lorsque l'utilisateur dispose de droits de modification / suppression
Boutons disponibles lorsque l'utilisateur ne dispose pas de droits de modification / suppression
Conception / Interface utilisateur
Notre objectif était de rendre la conception du phare aussi laconique et moderne que possible, tout en adhérant au style d'interface utilisateur ou de tableau de bord "traditionnel" de Kubernetes. Par exemple, nous sommes convaincus que la vue tabulaire familière est idéale pour le travail, et nous espérons que d'autres types de visualisation (par exemple, la représentation d'un cluster sous forme de graphiques) pourront être implémentés à l'aide de plugins.
Le frontend est implémenté dans React avec la bibliothèque Material UI (il est moderne, soigné et pris en charge par une large communauté d'utilisateurs). De plus, il est inclus dans la pile technologique de notre autre projet - Nebraska (gestionnaire de mise à jour pour Flatcar Container Linux - environ Transl.)nous permettant de partager des expériences et des ressources et d'assurer une interface utilisateur cohérente sur tous les produits.
Localement ou dans un cluster
La plupart des interfaces utilisateur Kubernetes se répartissent en deux groupes: distante (le backend est souvent dans un cluster) comme Kubernetes Dashboard ou locale (l'application est installée sur l'ordinateur) comme Octant de VMware.
Chacune de ces approches présente des avantages et des inconvénients. Par exemple, dans le cas d'une application distante, il est très facile de partager l'URL avec d'autres utilisateurs et d'implémenter leur connexion via OIDC. Il est disponible «partout» et est facile à tenir à jour. Au contraire, dans le cas de la version de bureau, il n'est pas nécessaire de penser à l'emplacement de l'interface utilisateur. Cette approche permet une meilleure isolation, mais il appartient à l'utilisateur de maintenir l'application à jour.
Avec Headlamp, vous n'avez plus à choisir entre ces deux approches: les deux sont prises en charge. La lampe frontale peut être facilement mise en cluster à l'aide de nos fichiers YAML (et en les adaptant pour vous), ou installée localement sur une machine Linux, macOS ou Windows.
Mode multi-cluster
La plupart des déploiements Kubernetes consistent en plusieurs clusters (au moins pour séparer les environnements de développement et de production). Headlamp permet d'accéder à tous ces clusters: la méthode spécifique dépend de si vous l'exécutez localement ou à distance.
Lorsqu'il est exécuté localement, Headlamp lira le kubeconfig et affichera les contextes disponibles, permettant à l'utilisateur de les modifier selon ses besoins, simplement en définissant la variable d'environnement locale sur le cluster approprié.
Le mode multi-cluster est très simple: un proxy est créé pour chaque cluster configuré et les requêtes de l'interface utilisateur (avec des appels à l'API Kubernetes) sont redirigées vers l'adresse du cluster souhaité. Le projet K8dash doit être mentionné ici, des modules de gestion des requêtes / API dont nous avons utilisé lors du développement de Headlamp.
Cette approche peut également être combinée avec l'exécution en cluster, mais pour ce faire, le cluster dans lequel l'application s'exécute aura besoin d'un accès API aux autres clusters spécifiés.
Connexion Lokomotive Kubernetes
Comme vous le savez probablement, nous avons également notre propre distribution Kubernetes - Lokomotive . Nous utilisons Headlamp chez Lokomotive aux fins prévues, mais nous tenons à souligner qu'il s'agit de projets indépendants et indépendants. Nous n'allons pas lier Headlamp à un fournisseur de services K8, et nous le concevons pour qu'il fonctionne sur n'importe quel cluster Kubernetes typique.
Essayez Headlamp sur votre cluster!
C'est très simple: déployez le déploiement dans votre cluster et accédez à l'adresse correspondante dans le navigateur, ou téléchargez et installez la version bureau pour Windows, macOS ou Linux. Les détails sont dans la documentation .
Headlamp est un outil entièrement open source publié sous la licence Apache 2.0. Comme mentionné ci-dessus, nous l'avons rendu indépendant des fournisseurs de services Kubernetes et polyvalent (couvrant un grand nombre de cas d'utilisation). Aujourd'hui, nous invitons tout le monde à participer au développement du projet! Pour ce faire, veuillez lire les directives pertinentes .
Nous espérons que vous apprécierez Headlamp!
PS du traducteur
Lisez aussi sur notre blog: