
Nous avons déjà
écrit sur les «assistants de console» pour Kubernetes il y a un an, et nous avons déjà
fait un aperçu des autres utilitaires utiles. Cependant, avec le développement des K8 et de sa communauté, l'écosystème associé subit également des changements. Par conséquent, nous avons encore une fois quelque chose à dire aux fans de la console. C'est parti!
kubebox
- GitHub (400+ étoiles)
- Langue: JavaScript (Node.js)
- Licence: MIT
Ce projet a été la raison de la rédaction de la revue. D'une part, il est un brillant représentant de la catégorie des logiciels «les geeks font pour les geeks», mais d'autre part, il a grandi au point où non seulement il plaît à l'œil, mais apporte également des avantages pratiques ...
Ainsi, le but de kubebox est de travailler pleinement avec Kubernetes dans le cadre d'une interface de console pratique présentée dans le style des pseudo-graphiques:

Le travail signifie des fonctionnalités telles que la navigation dans les pods à travers les espaces de noms, l'affichage des journaux et même des graphiques de consommation des ressources clés (CPU, mémoire, réseau), l'exécution à distance des commandes dans des conteneurs. Les paramètres de connexion aux clusters peuvent être extraits de la variable d'environnement
KUBECONFIG
ou des
KUBECONFIG
dans
$HOME/.kube
.
Les autres plans des développeurs incluent la prise en charge de la modification des configurations et de l'exécution des opérations CRUD, ainsi qu'une
refonte significative
de l'interface pour prendre en charge de nouveaux types de primitives (services, déploiements, etc.) et une navigation pratique avec des informations supplémentaires (en particulier,
kubectl describe pod
).
Une caractéristique importante est la disponibilité d'une
version en ligne (pour vous connecter au serveur API Kubernetes, vous aurez besoin des
cors-allowed-origins
). De plus, kubebox peut être lancé en tant que fichier exécutable séparé, en tant que client intégré au
cluster (via kubectl), ainsi qu'à partir d'un service déployé dans un cluster Kubernetes ou OpenShift (
Xterm.js est utilisé pour émuler le terminal).
Depuis près de 2 ans, un employé de Red Hat en France développe kubebox (pour être exact, même moins de 10% des commits ont été effectués par son collègue). Le projet n'a reçu une publicité suffisamment large que le mois dernier (sur
Reddit et un certain nombre d'autres ressources), on peut donc s'attendre à ce que cela donne un nouvel élan à son développement.
kube-shell et kube-prompt
kube-shell
- GitHub (950+ étoiles)
- Langue: Python
- Licence: Apache 2.0
(Attention, ce ~ 2 Mb GIF!)kube-prompt
- GitHub (700+ étoiles)
- Langue: Aller
- Licence: MIT

Nous avons déjà
écrit sur ces projets il y a un an, et à cette époque, ils étaient des favoris inconditionnels parmi les coques de console à part entière pour travailler avec Kubernetes. Les deux sont positionnés comme des interfaces améliorées (plus pratiques à utiliser) de kubectl. Dans kube-shell, ils utilisent la bibliothèque
prompt-toolkit pour Python, et pour kube-prompt ils ont pris et développé une bibliothèque similaire sur Go (
go-prompt ).
Si vous les comparez avec kubebox, alors l'interface n'est pas basée sur des pseudographies, mais sur la console habituelle pour entrer des commandes
(voir captures d'écran ci-dessus) , qui, cependant, s'accompagne d '«effets spéciaux» très intéressants: infobulles utilisant des commandes, ajout automatique pratique et etc.
Malgré le large éventail de fonctionnalités prises en charge (y compris le système développé d'astuces et d'auto-complétion déjà mentionné, une recherche de l'historique des commandes et un mode d'édition de type vi), l'
historique des validations dans kube-shell indique un net ralentissement du projet. Seuls sept commits ont été enregistrés cette année, dont deux sont des modifications du
README
. Bien qu'il y en ait eu quelques-uns utiles, par exemple, la
prise en charge tant attendue de la variable
KUBECONFIG
. D'une manière ou d'une autre, l'absence persistante de réaction des développeurs aux requêtes pertinentes pour les utilisateurs (voir les
problèmes ) n'inspire pas de bonnes perspectives.
La situation avec le développement de kube-prompt semble légèrement meilleure. Bien que ce projet ait marqué moins d'étoiles sur GitHub (si il y a un an, il était légèrement en avance sur son concurrent Python, il est désormais nettement en retard), les commits apparaissent plus ou moins régulièrement, et la dernière version (
1.0.5 ) est datée du 18 octobre. Cependant, il n'y a pas tant de changements significatifs au cours de la dernière année - nous notons la prise en charge de Kubernetes version 1.11 et la possibilité d'auto-complétion pour l'espace de noms. L'essentiel est que l'auteur lui-même
admette l' impossibilité de consacrer suffisamment de temps au développement de kube-prompt et recherche des aides.
En résumant les résultats de ces deux projets, nous pouvons dire que kube-shell a conservé son leadership en termes de capacités prises en charge et est allé de l'avant en popularité, mais avec les perspectives pour les deux coquilles, tout n'est pas clair. Cependant, si vous êtes à l'aise avec la façon dont ils fonctionnent actuellement, il n'y a aucune raison de ne pas les mettre en service, car aucune autre alternative de conception similaire n'est apparue.
Cliquez sur
- GitHub (750+ étoiles)
- Langue: rouille
- Licence: Apache 2.0
Click est un projet assez jeune: en version beta, il a été
présenté fin mars - et très intéressant à sa manière. Son concept se résume à utiliser kubectl dans une
boucle REPL , ce qui facilite la vie en maintenant un environnement constant. Ce dernier est que Click "se souvient" du contexte, de l'espace de noms, sous, etc., invitant l'utilisateur à exécuter la commande souhaitée pour la ressource donnée sans avoir à spécifier de nouveau tout ce "chemin".

L'idée du projet est née dans la société Databricks, où ils utilisent activement Kubernetes et sont fatigués d'observer le même scénario de travail avec kubectl, qui nécessite l'introduction constante de données précédentes. Dans le même temps, l'utilitaire kubectl lui-même - comme la console en général - est très populaire parmi les ingénieurs. Donc, ce complément est apparu, ne prétendant pas remplacer kubectl, mais aidant seulement à travailler avec lui. Un exemple d'utilisation pour Click est:
pods //
2 //
describe //
events //
logs -c foo > /tmp/podfoo.log //
delete // ( )
Si vous êtes intéressé, consultez également une
petite capture d'écran montrant le travail de Click avec des commentaires de texte.
Travailler avec des journaux
En prime - pas des shells, mais des outils de console pour travailler avec les journaux dans Kubernetes. Il y a un an, nous ne mentionnions que
k8stail en tant que tel, mais le passé a montré que le problème est pertinent et il existe d'autres solutions dignes d'attention pour le résoudre.
Stern
- GitHub (~ 1300 étoiles)
- Langue: Aller
- Licence: Apache 2.0
Stern est le favori incontesté de la queue pour la catégorie Kubernetes. Pour plus de clarté, lors de l'affichage des journaux, différents codes de couleur sont utilisés:

Une autre caractéristique importante est l'utilisation d'expressions régulières pour un filtrage pratique des foyers sans avoir besoin de connaître des ID spécifiques (par exemple, sélectionnez tout avec le nom
web-\w+
). De même (c.-à-d. Regexpams), vous pouvez filtrer des conteneurs spécifiques pour les modules demandés. Entre autres caractéristiques de la poupe:
- prise en charge des modèles Go personnalisés pour les journaux de sortie (il existe plusieurs prédéfinis par défaut);
- prise en charge des sélecteurs d'étiquettes;
- restriction de la sortie du journal à une valeur de temps spécifiée - depuis et / ou un nombre spécifié de lignes;
- prise en charge de la saisie semi-automatique pour bash et zsh, ainsi que la substitution dynamique des valeurs pour les espaces de noms et les contextes.
Kubetail
- GitHub (~ 950 étoiles)
- Langue: Shell
- Licence: Apache 2.0
Une solution similaire, écrite en Bash régulier et un peu plus activement développée l'année dernière. Comme la poupe, il prend en charge la mise en évidence des noms des foyers (ou toute la ligne personnalisable):

Il vous permet également de filtrer les pods et les conteneurs par les noms complets et les expressions régulières, ainsi que d'utiliser des sélecteurs, de limiter la sortie au temps et au nombre de lignes, et prend en charge la saisie semi-automatique pour Bash, zsh et fish. Entre autres fonctionnalités:
- mode de désactivation -
--follow
pour mettre à jour les données des journaux en temps réel (comme dans tail -f
); --dry-run
pour afficher une liste de pods et conteneurs appropriés sans effectuer d'autres actions;- prise en charge du sélecteur jq pour l'analyse de la sortie dans JSON.
Kail
- GitHub (~ 500 étoiles)
- Langue: Aller
- Licence: MIT
Une autre implémentation qui a connu le moins d'activité dans la base de code au cours de la dernière année. Cependant, il présente des caractéristiques fonctionnelles intéressantes qui diffèrent de ses concurrents, à savoir:
- restriction sur demande des foyers par les noms de leur service, ReplicationController, ReplicaSet, Deployment, Node et / ou Ingress (c.-à-d. foyers appartenant aux services auxquels conduit l'Ingress spécifié) ;
- la possibilité non seulement de sélectionner par des sélecteurs, mais également de les exclure;
- détermination du niveau de journalisation (
--log-level
).

Mais il y a aussi des inconvénients: kail ne met pas en évidence les pods avec des couleurs, ne prend pas en charge les expressions régulières pour les filtres.
PS
Merci de votre intérêt et, bien sûr, nous serons heureux d'entendre vos conclusions dans les commentaires!
Lisez aussi dans notre blog: