Supervision de Kubernetes

À partir de la version 2.2.0, Checkmk prend en charge les distributions et services Kubernetes suivants :

Notre objectif est de prendre en charge chacune des 5 dernières versions (mineures) publiées de Kubernetes. Nous prenons donc également en charge les versions de Kubernetes qui ne font déjà plus partie du cycle de vie (Vanilla) de Kubernetes. Avant tout, nous veillons à une collaboration harmonieuse avec les fournisseurs de cloud qui proposent également des périodes de support plus longues pour leurs services Kubernetes. Immédiatement après la sortie d’une nouvelle version de Kubernetes, il peut s’écouler un certain temps — en fonction de l’étendue des nouvelles fonctionnalités et du calendrier — avant qu’elle ne soit également entièrement prise en charge dans Checkmk. Dès que Checkmk pourra fonctionner sans heurts avec cette nouvelle version, nous l’annoncerons dans un Werk (tel que le Werk n° 14584).

Pour une introduction à la nouvelle supervision de Kubernetes, nous vous recommandons nos deux vidéos « Supervision de Kubernetes avec Checkmk » et « Détection des problèmes et configuration des alertes pour les clusters Kubernetes ».

Étant donné que les clusters Kubernetes peuvent subir rapidement des changements majeurs en termes de nombre et d’emplacement des composants individuels, nous vous recommandons de créer une instance distincte pour la supervision de votre environnement Kubernetes. Vous pouvez ensuite établir une connexion entre cette instance et votre instance centrale comme d’habitude via la supervision distribuée.

Checkmk effectue la supervision de vos clusters Kubernetes de deux manières :

L'agent spécial Kubernetes récupère simplement des informations de base via le serveur API de votre cluster. Cela permet déjà de récupérer les états des nœuds et des conteneurs. La plupart des métadonnées de vos pods et déploiements sont également obtenues de cette manière.

Pour une supervision complète, il manque toutefois encore quelque chose à ce stade. Des questions telles que la charge générée par un déploiement particulier sur le processeur, ou la quantité de mémoire actuellement utilisée par un DaemonSet, ne peuvent pas trouver de réponse de cette manière.

C’est là que notre Checkmk Node Collector et notre Checkmk Cluster Collector entrent en jeu. Ils constituent un élément indispensable de la supervision de Kubernetes au sein de Checkmk. Une partie non négligeable de ce qui suit dans cet article porte donc également sur leur installation et leur configuration. De plus, l’utilisation des tableaux de bord Kubernetes dans les éditions commerciales n’a de sens que si les Node et Cluster Collectors peuvent fournir des données sur les charges correspondantes.

Lors de la supervision des pods et des répliques dans vos clusters Kubernetes, les changements d’état ou les retards surviennent parfois beaucoup plus fréquemment. Pour tenir compte de cela, les contrôles portant sur certains états de ces objets ne modifient leur statut dans Checkmk qu’après 10 minutes.

La supervision Kubernetes dans Checkmk a été entièrement réécrite. L'étendue des données pouvant être supervisées s'est considérablement élargie. Étant donné que la base technique de la supervision Kubernetes dans Checkmk 2.1.0 est fondamentalement différente, il n'est pas possible de transférer ni même de réécrire les données de supervision antérieures de vos objets Kubernetes.

L'installation de la supervision Kubernetes s'effectue à l'aide de l'outil helm. Helm convient également aux utilisateurs moins expérimentés et standardise la gestion des configurations. Helm est une sorte de gestionnaire de packs pour Kubernetes. Si vous n'utilisez pas encore Helm, vous pouvez généralement vous le procurer via le gestionnaire de packs de votre distribution Linux ou sur le site web du projet Helm.

Vous pouvez utiliser Helm pour inclure des référentiels en tant que sources et ajouter facilement les Helm Charts qu’ils contiennent à votre cluster, de la même manière que des paquets. Commencez par identifier le référentiel. Dans l’exemple suivant, nous utilisons le nom « checkmk-chart » afin de faciliter l’accès au référentiel ultérieurement. Vous pouvez bien sûr utiliser tout autre nom de votre choix :

Nous mettons à jour nos Helm charts chaque fois que de nouveaux développements dans Kubernetes l'exigent. Il est donc utile de vérifier de temps à autre si de nouvelles versions sont disponibles dans le référentiel. Si vous avez nommé votre copie locale de notre référentiel checkmk-chart, comme dans l'instruction précédente, vous pouvez utiliser l'instruction suivante pour afficher toutes les versions des Helm charts disponibles dans le référentiel :

Si une version plus récente est disponible, vous pouvez effectuer la mise à jour avec helm repo update.

Comme nous ne pouvons pas connaître à l'avance la structure de votre cluster Kubernetes, nous avons choisi la variante la plus sûre pour le démarrage des Cluster Collectors : Par défaut, vous ne fournissez aucun port accessible à distance. Afin de pouvoir accéder aux Cluster Collectors ultérieurement, vous devrez adapter ces paramètres à votre cluster particulier.

Nous prenons en charge deux chemins d'accès par défaut : la requête via Ingress et la requête via NodePort. La configuration de ceux-ci variera en fonction de la variante que vous prenez en charge dans votre cluster.

Afin de pouvoir définir vous-même certains paramètres pour toutes les configurations, vous incluez un fichier de contrôle, appelé « values.yaml ».

Il existe deux façons de créer un tel fichier « values.yaml ». Vous pouvez soit extraire le fichier que nous fournissons dans les Helm charts et le modifier, soit créer vous-même une version minimale.

Chaque fois que vous souhaitez déployer des modifications apportées à ce fichier dans votre cluster, vous pouvez à nouveau utiliser l'instruction d'installation des Helm charts que nous aborderons plus loin dans cet article.

Après avoir personnalisé values.yaml ou créé votre propre chart, utilisez l’instruction suivante pour installer tous les composants nécessaires dans votre cluster afin de pouvoir le superviser dans Checkmk :

Comme cette instruction n'est pas intuitive, nous vous fournissons ci-dessous une explication des différentes options :

Une fois l’instruction exécutée, votre cluster Kubernetes est prêt à être supervisé avec Checkmk. Le cluster se chargera désormais de s’assurer que les pods nécessaires et les conteneurs qu’ils contiennent sont en cours d’exécution et accessibles.

Il est préférable de stocker le mot de passe (jeton) du compte de service dans le coffre-fort à mot de passe de Checkmk. Il s’agit de l’option la plus sûre, car elle vous permet de séparer, sur le plan organisationnel, le stockage et l’utilisation du mot de passe. Vous pouvez également saisir le mot de passe directement en texte clair lors de la création de la règle (voir ci-dessous). Pour savoir comment afficher le mot de passe requis, consultez la sortie du Helm chart. Ajoutez le mot de passe au coffre-fort à mot de passe de Checkmk à l’aide de la commande `Setup > General > Passwords > Add password`, par exemple sous l’ID et le titre « My Kubernetes Token » :

Pour que Checkmk fasse confiance à l'autorité de certification (CA) du compte de service, vous devez enregistrer le certificat CA dans Checkmk. La procédure pour afficher le certificat requis figure également dans la sortie du Helm chart. Copiez tout ce qui se trouve ici, y compris les lignes « BEGIN CERTIFICATE » et « END CERTIFICATE », puis ajoutez le certificat dans le menu de configuration sous « Setup > General > Global settings > Site management > Trusted certificate authorities for SSL » :

Créez un nouvel hôte dans Checkmk de la manière habituelle et nommez-le par exemple « mykubernetesclusterhost ». Comme le suggèrent le titre et le nom de l’hôte, cet hôte sert à collecter les données ferroutées ainsi qu’à effectuer l’affectation de tous les services et métriques au niveau du cluster. Étant donné que cet hôte ne reçoit des données que via l’agent spécial, veillez à définir l’option « IP address family » sur « No IP » dans les propriétés de l’hôte.

Pour garantir la séparation entre les objets de différents clusters Kubernetes, il peut être utile de créer un dossier par cluster via Setup > Hosts > Add folder, dans lequel la gestion dynamique des hôtes peut créer automatiquement tous les hôtes d’un cluster. La création ou l’utilisation d’un tel dossier est toutefois facultative.

Configurez ensuite une connexion dans les éditions commerciales pour les données ferroutées entrantes : avec Setup > Hosts > Dynamic host management > Add connection. Saisissez d'abord un titre, puis cliquez sur show more sous Connection Properties.

Cliquez ensuite sur « Add new element » et sélectionnez le dossier précédemment créé sous « Create hosts in ».

Laissez les attributs par défaut sous « Host attributes to set » tels quels. Ils garantissent que Checkmk se contente de suivre les données ferroutées pour les ordinateurs hôtes créés automatiquement et ne tente pas, par exemple, de les pinguer ou de les joindre via SNMP.

Dans un environnement Kubernetes où les objets surveillables et surveillés apparaissent et disparaissent en permanence, il est également recommandé d’activer l’option « Automatically delete hosts without piggyback data ». Le fonctionnement exact de cette option et les circonstances dans lesquelles les hôtes sont alors effectivement supprimés sont expliqués dans le chapitre « Suppression automatique des hôtes » de l’article sur la gestion dynamique des hôtes.

Saisissez maintenant l'hôte ferrouté précédemment créé sous « Restrict source hosts » et activez l'option « Discover services during creation ».

La section « Connection Properties » de cette nouvelle connexion pourrait alors se présenter comme suit :

Dans Checkmk Community, vous devrez créer manuellement les hôtes pour les données ferroutées accumulées. Étant donné qu'un grand nombre d'hôtes ferroutés est susceptible d'apparaître ici dans un cluster Kubernetes, nous vous recommandons d'utiliser l'instruction « cmk-piggyback list orphans ».

Par défaut, Checkmk effectue une reconnaissance du service toutes les deux heures et affiche le résultat de cette reconnaissance dans le service « Check_MK Discovery ». Vous trouverez ce paramètre dans le jeu de règles « Periodic service discovery ». Dans le contexte de Kubernetes, nous vous recommandons de créer une règle pour tous les ordinateurs hôtes portant l’étiquette « cmk/kubernetes:yes ». Cette étiquette est automatiquement attribuée par Checkmk à chaque ordinateur hôte représentant des objets Kubernetes. Vous devriez sélectionner ici un intervalle plus court pour la reconnaissance du service, et également activer l’option « Automatically update service configuration ». Les paramètres de la capture d’écran suivante ne sont que des exemples. Vous devrez décider au cas par cas de ce qui convient le mieux à vos clusters.

Pour limiter cette règle à tous les ordinateurs hôtes de votre cluster, il suffit de saisir « cmk/kubernetes:yes » dans le champ « Conditions » sous « Host labels ». Toutefois, si vous souhaitez créer des règles individuelles pour plusieurs clusters, utilisez simplement ici l'étiquette spécifique au cluster concerné. Ces étiquettes se présentent toujours sous la forme « cmk/kubernetes/cluster:mycluster ».

Maintenant que toutes les conditions préalables ont été créées dans le cluster et dans Checkmk, vous pouvez vous concentrer sur la configuration de l'agent spécial. Vous pouvez y accéder via Setup > Agents > VM, cloud, container > Kubernetes. Créez une nouvelle règle avec Add rule.

Tout d'abord, vous devez attribuer un nom au cluster à superviser. Vous pouvez choisir ce nom librement. Il sert à donner un nom unique à tous les objets provenant de ce cluster particulier. Par exemple, si vous saisissez ici mycluster, les noms des ordinateurs hôtes de tous les pods de ce cluster commenceront par la suite par pod_mycluster. La partie suivante du nom de domaine sera alors toujours l'espace de nommage dans lequel cet objet Kubernetes existe. Le nom de domaine d'un pod pourrait alors être pod_mycluster_kube-system_svclb-traefik-8bgw7, par exemple.

Sous « Token », sélectionnez maintenant l'entrée précédemment créée dans le coffre-fort à mot de passe Checkmk.

Sous « API server connection > Endpoint », Checkmk vous demande maintenant de saisir l’URL (ou l’adresse IP) via laquelle votre serveur API Kubernetes est accessible. Vous ne devez saisir le port que si le service n’est pas fourni via un hôte virtuel. La manière la plus simple de trouver cette adresse — si vous ne l’avez pas déjà sous la main — dépendra de votre environnement Kubernetes. L’instruction suivante vous donnera la ressource du serveur API dans la ligne « server » :

Cependant, le résultat réel de la commande « kubectl config view » varie considérablement. Si un port est également spécifié ici dans la ligne « server », veillez à l’inclure également dans la règle.

Si vous avez suivi ces instructions étape par étape jusqu’à présent et que vous avez déposé le certificat CA de votre cluster — comme décrit ci-dessus — dans Checkmk, sélectionnez sous « SSL certificate verification » l’entrée « Verify the certificate ».

Vous avez ensuite la possibilité d’enrichir la supervision de votre cluster Kubernetes avec les données de charge de travail collectées par le Checkmk Cluster Collector. Nous le répétons ici une fois de plus pour en souligner l’importance : la configuration du Cluster Collector est absolument essentielle pour une supervision complète de vos clusters. C’est le seul moyen d’obtenir des données importantes telles que l’utilisation du processeur et de la mémoire, et de recevoir des informations sur les systèmes de fichiers utilisés par les composants individuels.

Activez donc l’option « Enrich with usage data from Checkmk Cluster Collector » et spécifiez la ressource du NodePort ou de l’Ingress. La manière d’afficher cette ressource est indiquée dans la sortie du Helm chart.

Grâce aux options d'Collect information about…​, vous pouvez désormais sélectionner les objets de votre cluster qui doivent faire l'objet de la supervision. Notre présélection couvre les objets les plus pertinents. Si vous décidez de faire l'objet de la supervision l'Pods of CronJobs, veuillez vous reporter à l'aide en ligne à ce sujet.

Les deux options suivantes vous permettent de limiter davantage les objets à superviser. Si vous ne souhaitez superviser que les objets de certains espaces de nommage, configurez ce paramètre en conséquence sous « Monitor namespaces ». Vous pouvez ici soit saisir les espaces de nommage individuels à superviser, soit exclure explicitement certains espaces de nommage de la supervision.

L'option « Cluster resource aggregation » vous permet de spécifier les nœuds qui ne fournissent pas de ressources pour la charge de travail de votre cluster. Ces nœuds doivent être exclus du calcul des ressources disponibles, sinon vous risquez de ne pas détecter les goulots d'étranglement de capacité. Par défaut, nous excluons donc les nœuds control-plane et infra de l'évaluation.

En dernier lieu, vous pouvez importer les annotations de Kubernetes. Dans Checkmk, ces annotations deviennent des étiquettes d'hôte et peuvent ainsi être utilisées comme conditions dans les règles. Vous pouvez spécifier les annotations à importer à l'aide d'expressions régulières. Là encore, veuillez consulter l'aide en ligne détaillée à ce stade.

Remarque : l'option « Import all valid annotations » (Importer toutes les annotations) n'est fournie ici que par souci d'exhaustivité. Nous vous déconseillons d'importer aveuglément toutes les annotations, car cela peut créer une montagne d'étiquettes inutiles dans Checkmk.

Important : Sous « Conditions > Explicit hosts », vous devez maintenant saisir l'ordinateur hôte créé précédemment :

Enregistrez ensuite la règle et effectuez une reconnaissance du service sur cet ordinateur hôte. Vous verrez immédiatement apparaître ici les premiers services au niveau du cluster :

Activez maintenant toutes les modifications que vous avez apportées et laissez la gestion dynamique des hôtes faire le travail à votre place. Cela créera tous les hôtes pour vos objets Kubernetes en très peu de temps.

Les éditions commerciales de Checkmk sont fournies avec six tableaux de bord intégrés pour Kubernetes. Afin d'utiliser ces tableaux de bord de manière pratique, il est nécessaire d'installer et de configurer notre Cluster Collector. Plus précisément, ces six tableaux de bord s'intitulent :

Le point d'entrée est toujours le tableau de bord d'Kubernetes, auquel vous pouvez accéder via Monitor > Applications > Kubernetes :

Dans le tableau de bord « Kubernetes », tous vos clusters Kubernetes sous supervision sont répertoriés sur le côté gauche. Cette liste de clusters constitue également votre point d'entrée pour explorer plus en détail les tableaux de bord Kubernetes. En cliquant sur le nom d'un cluster, vous accédez au tableau de bord « » du cluster sélectionné. Dans le tableau de bord « Kubernetes Cluster », cliquer sur le nom correspondant vous permet d'accéder aux autres tableaux de bord dépendants du contexte :

La supervision Kubernetes de Checkmk prend également en charge l’inventaire matériel/logiciel. Par exemple, si vous cliquez sur le nom principal du cluster (ici : mycluster) dans le tableau de bord du cluster ci-dessus, vous accéderez à l’inventaire du cluster.

De la même manière, c'est-à-dire via les cases contenant les noms principaux des objets, vous accéderez également à l'inventaire de l'objet correspondant dans les autres tableaux de bord. L'exemple suivant montre l'inventaire matériel/logiciel d'un pod :