Nous sommes heureux d'annoncer un nouveau développement Open Source de la société Flant pour les spécialistes DevOps et pas seulement
kubedog . Il s'agit d'une bibliothèque Go-écrite et d'une CLI basée sur elle pour suivre les événements de ressources Kubernetes et collecter leurs journaux.
La bibliothèque prend actuellement en charge le suivi des ressources suivantes: Pod (et conteneur), Job, Deployment, StatefulSet et DaemonSet. Les événements et les journaux sont transmis via des rappels.
La CLI kubedog a deux modes de fonctionnement:
- piste de déploiement - suivi de la ressource jusqu'à ce que l'état Prêt soit atteint et sortie en cas d'erreur pour une utilisation pratique dans CI / CD;
- Follow - affiche les événements et les journaux à l'écran sans quitter, similaire à
tail -f .
Le problème
Pourquoi avons-nous commencé à écrire une nouvelle bibliothèque si des projets similaires existent déjà
(voir «Utilisation des journaux» dans cette revue ) ? Kubedog est utilisé dans notre
utilitaire dapp DevOps pour suivre
le déploiement des graphiques Helm. Helm lui-même ne sait pas comment surveiller l'état des ressources qu'il ajoute, et le transfert de journaux n'est pas fourni au niveau de l'interaction GRPC entre Helm et tiller. A cette occasion, il y a
notre numéro 3481 , dans le cadre duquel nous avons implémenté le suivi des ressources ajoutées ... Cependant, le projet Helm est maintenant réticent à ajouter de nouvelles fonctionnalités à Helm 2, puisque tous les efforts sont concentrés sur la nouvelle version de
Helm 3 . Pour cette raison, nous avons décidé de séparer kubedog en un projet distinct.
De quoi a besoin la bibliothèque de suivi des ressources?
- Obtenez des journaux des pods qui appartiennent à une ressource - par exemple, Déploiement.
- Répondez aux changements dans la composition des pods qui appartiennent à la ressource: ajoutez des journaux de réception de nouveaux pods, désactivez les journaux des pods d'anciens ReplicaSets.
- Événements de suivi dans lesquels des décryptages de diverses erreurs surviennent. Par exemple, un pod ne peut pas être créé en raison d'une image inconnue ou un pod est créé, mais la commande spécifiée dans le modèle n'est pas dans l'image.
- Et une autre exigence est le suivi de la transition d'une ressource du
rollout au mode ready . Et chaque ressource a ses propres conditions pour cela.
Comme vous pouvez le deviner, dans kubedog, nous avons essayé de
prendre en compte tout ce qui précède .
Dans le bon sens, au début des travaux sur quelque chose de nouveau, ils analysent les solutions existantes. Mais il s'est avéré que bien qu'il existe de nombreuses solutions sous la forme de la CLI, il n'y a tout simplement pas de bibliothèque Go. Par conséquent, nous ne pouvons donner qu'une petite comparaison des principales fonctionnalités des utilitaires CLI existants pour le suivi des ressources Kubernetes.
Solutions existantes
kubespy
→
GitHub- Capable de surveiller uniquement le déploiement et le service, réagit aux nouveaux pods.
- Il existe un mode de suivi pour la description de la ressource et son état et la sortie des changements sous la forme de diff json.
- Il existe une représentation tabulaire en couleur des modifications indiquant l'état des ReplicaSets et des conditions.
- N'affiche pas les journaux de pod.
- Il est écrit en Go, mais ne peut pas être utilisé comme bibliothèque.
kubetail
→
GitHub- Un script bash qui appelle kubectl.
- Capable d'afficher les journaux des pods existants.
- Il ne détecte pas les nouveaux pods; en cas de restauration, kubetail doit être redémarré.
sévère
→
GitHub- Affiche les journaux des pods filtrés par pod-query.
- Découvrez de nouveaux pods.
- Les lignes de journal sont colorées pour une meilleure perception.
- Affiche les événements d'ajout et de suppression de pods avec les noms des conteneurs qu'ils contiennent.
- Il ne suit pas les événements, il ne montre donc pas la cause des erreurs du pod.
- Il est écrit en Go, mais il ne peut pas être utilisé comme bibliothèque.
kail
→
GitHub- Capable d'afficher les journaux simultanément à partir de différents espaces de noms pour différentes ressources.
- Ne surveille pas les événements, n'affiche pas la cause des erreurs, par exemple, pour le déploiement.
- Ne peint pas les journaux des pods.
- Il est écrit en Go, mais il ne peut pas être utilisé comme bibliothèque.
k8stail
→
GitHub- Une sélection de pods par espace de noms et étiquettes.
- Garde la trace des nouveaux, suppression.
- Ne suit pas les événements, n'affichera pas d'erreurs.
- On Go, mais pas une bibliothèque.
kubedog
→
GitHub- La CLI fonctionne en deux modes: suivi sans fin et suivi jusqu'à ce que la ressource passe au statut READY.
- Assure le suivi d'une ressource.
- Réagit aux changements de ressources, s'abonne aux journaux des nouveaux pods.
- Capable de surveiller le déploiement, StatefulSet, DaemonSet, Job ou un pod séparé.
- Écrit dans Go, vous pouvez l'utiliser comme une bibliothèque pour ajouter des ressources à votre programme pour surveiller l'état des ressources et recevoir des journaux des conteneurs.
Si vous regardez de plus près, vous pouvez dire que chaque utilitaire surpasse en quelque sorte ses concurrents et qu'il n'y a pas un seul gagnant qui peut faire tout ce que les autres font.
Alors kubedog!
L'essence du travail de kubedog est la suivante: pour la ressource spécifiée, exécutez Watchers on Events et sur les pods appartenant à la ressource, et lorsque Pod apparaît, lancez son enregistreur. Tout ce qui se passe avec la ressource est diffusé au client en appelant des rappels.
Regardons un exemple de DaemonSet, qui est disponible pour le code qui utilise la bibliothèque. L'interface de rappel pour Deployment, StatefulSet et DaemonSet est la même * - c'est
ControllerFeed :
type ControllerFeed interface { Added(ready bool) error Ready() error Failed(reason string) error EventMsg(msg string) error AddedReplicaSet(ReplicaSet) error AddedPod(ReplicaSetPod) error PodLogChunk(*ReplicaSetPodLogChunk) error PodError(ReplicaSetPodError) error }
* L'exception est
AddedReplicaSet , qui n'a de sens que pour le déploiement (vous ne pouvez pas définir cette méthode pour suivre DaemonsSet).
Explications pour d'autres méthodes d'interface:
Added correspond à l'événement watch.Added de l'observateur pour la ressource sélectionnée;Ready est appelé lorsque la ressource est entrée dans l'état Ready (par exemple, pour DaemonSet, c'est le moment où le nombre de pods mis à jour et disponibles coïncide avec le nombre de pods «souhaité»);Failed - cette méthode est appelée lorsqu'une ressource est supprimée ou dans le cas où un événement est reçu avec la cause et la description de l'erreur (par exemple, FailedCreate );EventMsg est appelé pour chaque événement reçu de la ressource ou de ses pods: ce sont des événements sur la création de la ressource, sur le téléchargement d'image, etc. Y compris les messages d'erreur;AddedPod - une méthode par laquelle vous pouvez saisir les moments de création de nouveaux pods;PodLogChunk est appelé lorsqu'un autre morceau de journaux provient de l'API Kubernetes;PodError sera PodError si Pod échoue.
Chaque rappel peut renvoyer une
StopTrack type
StopTrack et le suivi sera terminé. Ainsi, par exemple, fait dans le suivi du déploiement -
Ready StopTrack et CLI termine son travail.
Pour faciliter la définition des rappels, il existe une structure
ControllerFeedProto , lors de la création d'un objet dont vous pouvez déterminer la méthode de rappel souhaitée.
Voici à quoi
ressemble , par exemple, la
sortie sans fin des journaux DaemonSet sans informations supplémentaires sur les événements et l'état:
Le dernier appel est
bloquant : il démarre une boucle sans fin de réception d'événements de Kubernetes et appelle les rappels correspondants. Vous pouvez interrompre ce cycle par programme en renvoyant
StopTrack partir du rappel.
Exemples d'application
L'utilisation de kubedog comme bibliothèque
peut être vue dans l'utilitaire dapp. C'est là que les trackers de déploiement prêts à l'emploi s'exécutent pour vérifier les ressources que Helm crée ou met à jour.
Kubedog CLI est en mesure d'
aider au déploiement dans le système CI / CD , indépendamment de son utilisation: kubectl, Helm ou autre chose. Après tout, vous pouvez exécuter
kubectl apply , puis
kubedog rollout track , et vous verrez une erreur dans les journaux de
kubedog rollout track si quelque chose ne va pas avec la ressource. Cette utilisation de kubedog contribuera à réduire le temps de diagnostic des problèmes de déploiement.
Et ensuite?
Nous prévoyons de développer la bibliothèque dans le sens de soutenir davantage de ressources - par exemple, je veux vraiment suivre Service et Ingress. De plus, il est censé effectuer des travaux sur la classification de la
reason dans Event'ah, afin de déterminer plus précisément le moment où l'on peut supposer que le déploiement de la ressource a échoué. Un autre vecteur de développement de bibliothèque est le suivi de plusieurs ressources à la fois, par exemple, par
labelSelector ou par espace de noms. Je veux également prendre en charge diverses annotations qui peuvent changer la nature du suivi, par exemple, pour les crochets Helm, mais cela est encore plus pertinent pour dapp.
Dans un avenir proche, l'accent sera mis sur la bibliothèque, mais des améliorations sont également prévues pour la CLI: commandes et drapeaux plus pratiques, coloration des journaux, messages sur la suppression des pods, comme dans la poupe. Nous envisageons également la possibilité de créer un mode interactif avec une table d'état de déploiement et des événements dans une fenêtre et avec des journaux dans une autre.
Comment essayer?
Les versions CLI de kubedog pour Linux et macOS sont disponibles sur
bintray .
J'ai vraiment hâte de recevoir vos commentaires et problèmes sur
GitHub !
PS
Lisez aussi dans notre blog: