Nous préférons vous avertir : cet article n’a rien à voir la console « Commodore 64 des gameurs des années 80 » mais bien sur Komodor, cette solution qui facilite la gestion de vos clusters Kubernetes. Et c’est Benjamin, ingénieur au sein du département Cloud & DevOps Solutions du centre d’expertises de Qim info, qui sera votre guide pour vos premiers pas sur la plateforme.
Avant de vous expliquer pourquoi Komodor est un outil génial, revenons un peu sur ce qu'est Kubernetes...
Kubernetes est un outil open-source d’orchestration de conteneurs applicatif, distribué sur un ensemble de nœuds de calcul. Il améliore l’efficacité de la livraison et la mise à jour des applications aux utilisateurs finaux. En complément, il apporte également une meilleure résilience face aux incidents et pannes, tout en garantissant la montée en charge.
Cependant, Kubernetes apporte aussi son lot de nouvelles problématiques, notamment sur la partie dépannage et débogage.
Par exemple, prenons un développeur qui voudrait comprendre pourquoi son application ne fonctionne pas lors d’une livraison. Il peut utiliser des outils comme le Kubernetes Dashboard ou la ligne de commande kubectl pour chercher des informations. Mais ces méthodes se révèlent complexes d’utilisation si l’on manque de temps ou d’expérience.
C’est pour palier à ce type de problématiques que sont apparus sur le marché des produits comme Komodor.
Mais alors qu'est-ce que Komodor ?
Komodor est un outil d’administration, de supervision et de débogage/dépannage en mode SaaS, qui va s’intégrer au sein de clusters Kubernetes.
Il observe l’état de santé de chaque composant et/ou application et peut s’intégrer à des solutions tierces (Ops Genie, Slack, DataDog, Sentry..) pour vous avertir au besoin. Il s’intègre également à des gestionnaires de sources comme Gitlab ou Github, pour corréler les commits avec les événements sur le cluster.
Il permet également d’afficher des recommandations et bonnes pratiques par rapport à la déclaration de fichiers YAML dans Kubernetes.
Et combien est-ce que ça coûte ?
Rien ! Komodor est un freemium avec une licence gratuite allant jusqu’à 50 nodes (tout cluster confondu). Cependant, la durée de rétention des données n’est que de 4 heures.
Il existe un plan Business et Enterprise avec des fonctionnalités supplémentaires comme l’utilisation de l’API Komodor ou l’utilisation de SSO.
C'est parti pour découvrir l'outil !
Pré-Requis
- Avoir accès à un cluster Kubernetes connecté à internet.
- Avoir le client en ligne de commande kubectl et helm.
- Avoir des autorisations suffisantes pour créer les ressources. Nous vous conseillons le rôle de ‘cluster-admin’. Les permissions spécifiques sont listées ici.
Commencez par créer un compte. Vous pouvez utiliser des services de SSO comme Google, Github ou Microsoft. Une fois votre compte créé, déployez un agent dans votre cluster Kubernetes avec la ligne de commande Helm.
Simplify Kubernetes Operations in 5 minutes.
Choisissez quel contexte Kubernetes doit être utilisé pour le déploiement de l’agent Komodor ainsi que le nom à afficher dans l’interface Komodor pour votre cluster. Une fois ces informations saisies et validées, revenez sur l’interface Web et cliquez sur « Check Connection ».
Vous avez reçu un message de confirmation à l’issue de l’installation ? Parfait.
Faisons ensuite un rapide tour de l'interface...
En vue principale se trouve les « Services » Komodor. Il s’agit d’objets Deployments /Daemonsets/Statefulsets au sens Kubernetes, c’est-à-dire toutes les applications présentes sur le cluster.
A gauche, le menu de sélection vous permet de parcourir les différentes ressources du cluster. Vous y trouverez les « Jobs », ainsi qu’une entrée « Events » qui recense tous les évènements de l’ensemble des « Services ». La vue « Ressources » Kubernetes (Nodes/Storage/Workloads..) est similaire au projet kubernetes-dashboard.
L'intégration de logiciels tiers à l'outil Komodor
Cette fonctionnalité est disponible dans la partie basse du menu Komodor.
Ici, nous prenons l’exemple de Slack pour recevoir des alertes en cas d’incidents sur les « Services ».
Dans « Intégrations » choisissez Slack, puis liez le compte.
Ensuite, créez un objet « Monitor » qui vous permettra de transmettre les alertes à Slack sur le bon canal.
Maintenant que les alertes sont paramétrées, testons le déploiement d’une base de données pour un projet.
Créez un StatefulSet ‘mydb-postgresql’ qui sera déployé dans le namespace Kubernetes « my-db » :
- kubectl create namespace my-db
- kubectl config set-context –current –namespace=my-db
- helm install mydb bitnami/postgresql
Après l’installation du chart Helm, l’application apparait dans la vue
« Services ». Pour afficher les détails des événements collectés par Komodor, cliquez sur « Service ».
Une fois le service déployé et fonctionnel, essayons une modification hasardeuse sur l’objet Kubernetes Statefulset
Changez la version de l’image Docker pour une autre version plus récente :
kubectl patch statefulset mydb-postgesql –type=’json’ \
-p='[{« op »: « replace », « path »: »/spec/template/spec/containers/0/image », « value »: » postgresql:15.1.0-debian-11-r32″}]’
La modification a échoué ! Une alerte est immédiatement envoyée sur le canal Slack :
Avec une erreur « Back-off pulling image »docker.io/bitnami/postgresql:15.1.0-debian-11-r32″, nous observons qu’un nouvel événement est apparu dans Komodor (cliquez sur l’image pour l’afficher en plein écran) :
L’item « Availability issue » décrit l’incident. C’est dans cette vue que vous pourrez identifier ce qui pose problème et l’analyser grâce à « Live Pods & Logs » et aux événements liés aux Pods.
En observant la partie événements sur le Pod, vous remarquerez que l’image n’est pas disponible sur le dépôt distant et donc que Kubernetes n’arrive pas à démarrer le conteneur.
L’évènement « Deploy » en rouge, indique quant à lui qu’une modification a été réalisée sur l’objet StatefulSet : consultez le différentiel qui compare ligne par ligne les modifications entre les deux versions.
Depuis cette vue, vous trouverez également l’option de « Rollback » pour revenir à l’état précédent.
Mais attention à comment sont gérées vos applications ! Si elles sont en mode
« GitOps » cette action ne sera d’aucune utilité, tout changement étant automatiquement écrasé par votre outil de Continuous Delivery (eg : ArgoCD).
Une fois le « RollBack » effectué, votre service est à nouveau opérationnel avec l’ancienne version de l’image.
Autre cas de figure : vous venez de déployer une nouvelle version mais le Pod dans Kubernetes crashe. Komodor affiche les journaux du dernier crash afin de comprendre la cause de l’erreur.
Et Komodor vous permet également d'intégrer des liens externes sous forme d’annotations !
Vous souhaitez rajouter un lien vers de la supervision avec Grafana ? Il vous suffit d’annoter l’object Statefulset dans Kubernetes :
kubectl annotate sts mydb-postgresql app.komodor.com/service.link.grafana-overall-system-health=my-link.grafana.com
Komodor va prendre en compte ces annotations et afficher un lien dans la partie détails d’un événement. Ce lien vous redirigera vers un tableau Grafana affichant les métriques CPU/Mémoire/IO…par rapport au Statefulset mydb-postgresql.
Petit conseil sur les bonnes pratiques...
Dans les « Services », nous retrouvons une section « Info » qui en plus de donner des informations sur l’applicatif, propose des « Best Practices » pour améliorer la conformité de vos ressource Kubernetes.
Alors si l'on résumait : pourquoi utiliser Komodor ?
Une prise en main facile
L'intégration à des logiciels tiers
Tout comme nous l’avons fait avec Slack, il est possible d’intégrer Komodor à une multitude d’outils utilisés dans le monde DevOps !
Si vos équipes utilisent des outils de gestion d’incidents comme PagerDuty ou Ops Genie, Komodor peut envoyer les incidents et leurs détails directement à ces applications.
Une plus grande visibilité pour les DevOps
Komodor centralise les informations pour enquêter sur un problème et, de manière générale, offre une meilleure vision lors des phases de débogage.
Il s’intègre facilement avec des outils comme Grafana ou Datadog sur les déploiements et permet d’administrer la partie Kubernetes (maintenance des nœuds, rollbacks, édition des ressources en YAML …)
En bref, votre équipe DevOps n’a pas le temps ou les ressources nécessaires pour maintenir un outil de débogage/résolution d’incidents on-Premise pour Kubernetes ? Komodor est la solution qui vous convient !
