[ad_1]

Introduire Murre pour une surveillance continue des conteneurs Kubernetes

Photo par Isaac Smith sur Unsplash

La plate-forme de référence pour le déploiement d’applications est désormais Kubernetes. D’une part, ses clusters peuvent inclure des centaines de ressources telles que des pods et des déploiements, et il est composé de plusieurs composants et opérateurs définis par l’utilisateur.

La variété des services, des applications et des réseaux encapsulés dans les ressources rend difficile pour les utilisateurs de comprendre le fonctionnement de Kubernetes. Il existe de nombreuses parties différentes, telles que ce qui se passe à l’intérieur du conteneur, quel pod exécute des requêtes spécifiques et pourquoi la requête n’est pas exécutée avec succès. Par conséquent, l’équipe de gestion du cloud doit conserver l’observabilité et surveiller l’état de santé des ressources.

L’observabilité implique trois aspects : la journalisation, le traçage et les métriques. Grâce à la journalisation, nous pouvons comprendre les opérations de l’application. Le traçage nous permet de savoir où se situe le problème. Enfin, les métriques indiquent l’utilisation des ressources et l’état de santé général du cluster.

par auteur

C’est aussi l’un des domaines les plus investis de la communauté CNCF. L’image suivante répertorie tous les projets concernant l’observabilité dans CNCF, dont beaucoup que je n’ai jamais utilisés ou connus auparavant.

La source

Les outils de surveillance se concentrent généralement sur la collecte et l’agrégation de métriques. Mais pour obtenir l’utilisation du processeur et du MEM des nœuds, des pods et des conteneurs dans le cluster, Dialecteun outil Go de surveillance open source sans dépendance, fait mieux que les outils de cette liste.

Avant d’explorer Murre, prenons Prometheus + Grafana et kubectl Top commande comme exemples pour voir comment fonctionnent les outils de surveillance sans dépendance et quels sont les avantages de Murre.

Prométhée + Grafana

En tant que solution de surveillance Kubernetes la plus populaire, elle nous aide à obtenir l’utilisation du processeur et du MEM du nœud correspondant, comme node_memory_Buffers_bytescomme indiqué ci-dessous :

La source

Cependant, les métriques de Prometheus doivent mapper chaque pod/conteneur/nœud un par un, et les différentes clés de métrique pour CPU et MEM rendent impossible de voir intuitivement la relation entre pod et conteneur.

Par exemple, pour observer le MEM et le CPU du conteneur, vous devez configurer container_memory_working_set_bytes et container_cpu_usage_seconds_total, respectivement. La courbe d’apprentissage de Prometheus est également très abrupte, car elle oblige les utilisateurs à se familiariser avec ses clés de métriques et ses fonctions agrégées (sum, rateetc.).

En plus du besoin d’installation et de configuration, Prometheus et Grafana sont trop volumineux et compliqués pour surveiller l’utilisation des ressources.

Haut Kubectl​

Le classique kubuctl top La commande nous permet de visualiser l’utilisation des ressources du nœud/pod.

Cette commande nécessite que metrics-server soit correctement configuré et fonctionne sur le serveur.​

Tout d’abord, nous devons installer serveur de métriques, qui n’est pas fourni avec Kubernetes. Mais la plupart des fournisseurs de Cloud l’ont déjà par défaut puisque les deux Autoscaler de pod horizontal et Autoscaler de pod vertical besoin pour fonctionner. Cependant, vous devez toujours installer un serveur de métriques si vous configurez manuellement le cluster Kubernetes.

Maintenant, nous pouvons obtenir une utilisation des ressources séparée avec kubectl top node et kubectl top podrespectivement.

Concernant les défauts, l’un est qu’il s’appuie sur metrics-server, ou la commande lance le Metrics API not available Erreur. Et la configuration par défaut du processeur 100m et de la mémoire 200MiB ne peut fonctionner correctement que lorsque le cluster a moins de 100 nœuds et 70 pods par nœud. L’autre est qu’il ne montre pas l’utilisation des ressources du conteneur ; il affiche uniquement la dernière utilisation des ressources de pod et de nœud à chaque fois et ne peut pas être mis à jour en continu.

Prométhée et kubectl top peut répondre à nos besoins dans une certaine mesure. Mais si vous creusez un peu plus, vous voyez que Prometheus dépend de kube-state-metrics, et top dépendent de metrics-server, qui utilisent tous deux l’API metrics. En ce qui concerne leurs différences, metrics-server se concentre sur la lecture des données au niveau du cluster, tandis que kube-state-metrics se concentre sur la lecture des données pour différents types de ressources, par exemple, les déploiements et les répliques.

la source

J’ai utilisé la commande top pour déboguer l’utilisation des ressources des nœuds et des pods avant de trouver Murre, un outil open source sans dépendance qui est nettement plus efficace.

par auteur

Murre montre l’utilisation des ressources des pods et des conteneurs sous chaque espace de noms et les met à jour en temps réel. Et il prend également en charge le tri par CPU/MEM.​

La seule chose nécessaire est d’installer Murre, mais pas de dépendances, dans le cluster. Parce qu’il ne repose pas sur APIServer mais obtient des informations sur les pods/conteneurs en temps réel via client-go, il formate et affiche ce qu’il obtient dans le terminal (tout comme la façon dont les plugins kubectl sont implémentés). L’installation est très simple :

go install github.com/groundcover-com/murre@latest
La source

Le code est facile à mâcher et à digérer : la logique d’obtention des métriques réside dans la GetContainers fonction dans fecher.go, obtenir la PodList et parcourir les conteneurs.

Des mises à jour régulières sont Fini en utilisant Aller timer.Ticker + selectet peut être configuré avec le --interval paramètre.​

Dans cet article, nous avons examiné la surveillance des K8 sans dépendance et comment elle se compare à la surveillance sans dépendance. Murre est un outil efficace pour observer l’utilisation des ressources des pods et des conteneurs sans installer de dépendances dans le cluster. Bien qu’il en soit encore au stade initial et qu’il attende d’être perfectionné, je peux imaginer qu’il deviendra plus puissant lorsque d’autres fonctions seront ajoutées, telles que l’affichage de métriques de déploiements, de répliques, d’APIServer, etc.​

Merci d’avoir lu! Restez à l’écoute pour plus.

[ad_2]

Télécharger ici

Leave a Reply

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Instagram

Ce message d’erreur n’est visible que pour les administrateurs de WordPress

Erreur. Aucun flux trouvé.

Veuillez aller sur la page de réglages d‘Instagram Feed pour connecter votre compte.