Supervision d’OpenShift

Étant donné que les clusters OpenShift peuvent également subir très rapidement des changements importants en termes de nombre et d'emplacement des composants individuels, nous vous recommandons de créer une instance Checkmk distincte pour la supervision d'un environnement OpenShift. Elle peut ensuite être connectée à l'instance centrale comme d'habitude via la procédure de supervision distribuée.

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

Vous devez d'abord configurer un espace de nommage et un compte de service pour Checkmk dans votre cluster OpenShift. Le moyen le plus rapide d'y parvenir est d'utiliser l'interface CLI d'OpenShift (oc en abrégé).

Dans l'exemple suivant, nous nommerons cet espace de nommage « checkmk-monitoring ». Si vous souhaitez ou devez choisir un autre nom, vous devrez également effectuer cette modification lors de la création du compte de service.

Le compte de service, avec son rôle associé et ce que l'on appelle le RoleBinding, peut être créé en spécifiant notre fichier YAML prêt à l'emploi publié sur GitHub. Checkez son contenu, puis exécutez l'instruction suivante :

Vous pouvez également télécharger d'abord ce fichier YAML, le personnaliser selon vos besoins, puis appliquer la commande « oc apply -f » à cette copie locale du fichier.

Grâce à l'outil en ligne de commande oc, vous pouvez désormais également extraire toutes les informations de votre cluster, que vous devrez généralement spécifier pour configurer l'agent spécial. Si vous avez modifié le nom du compte de service ou l'espace de nommage, vous devez modifier ces informations comme décrit pour les instructions suivantes.

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. C'est l'option la plus sûre, car elle vous permet de séparer de manière organisée 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 ajouter le mot de passe au coffre-fort à mot de passe de Checkmk, accédez à Setup > General > Passwords > Add password. Dans notre exemple, nous utilisons My OpenShift Token comme identifiant et titre :

Pour que Checkmk fasse confiance à la chaîne de certificats du compte de service, vous devez l’enregistrer dans Checkmk. Copiez tout ce qui se trouve ici — y compris les lignes contenant 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 « myopenshiftclusterhost ». Comme le suggèrent le titre et le nom de l’hôte, celui-ci 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 reçoit des données exclusivement 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. Validez l’ensemble de cette configuration en cliquant sur le bouton « Save & view folder ».

Pour garantir la séparation entre les objets de différents clusters Kubernetes, il est généralement pratique 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 et l’utilisation d’un tel dossier sont toutefois facultatives.

Configurez ensuite une connexion pour les données ferroutées entrantes. Pour ce faire, accédez à Setup > Hosts > Dynamic host management > Add connection. Saisissez d'abord un titre, puis sous « Connection Properties », cliquez sur « show more ».

L'étape suivante, très importante, consiste à saisir l'hôte ferrouté précédemment créé sous « Restrict source hosts ».

Ensuite, sous « Piggyback creation options », cliquez sur « Add new element » et, sous « Create hosts in », sélectionnez le dossier créé précédemment.

Vous pouvez laisser les attributs par défaut sous « Host attributes to set » tels quels. Ceux-ci garantissent que Checkmk n'accepte que les données ferroutées provenant des ordinateurs hôtes créés automatiquement et ne tente pas, par exemple, de les pinguer ou d'y accéder via SNMP.

Dans un environnement OpenShift où les objets surveillables et surveillés apparaissent et disparaissent en permanence, il est généralement recommandé d’activer également 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 consacré à la suppression automatique des hôtes de l’article sur la gestion dynamique des hôtes.

Enfin, activez l'option « Discover services during creation ».

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

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 d’OpenShift, nous vous recommandons de créer une règle avec l’étiquette « cmk/kubernetes:yes » pour tous les ordinateurs hôtes. En effet, chaque hôte représentant des objets Kubernetes reçoit automatiquement cette étiquette de la part de Checkmk. Dans ce cas, vous devriez choisir un intervalle plus court que deux heures pour la reconnaissance du service, et également activer l’option « Automatically update service configuration ». Les paramètres de la capture d’écran ci-dessous ne sont que des exemples. Vous devrez déterminer au cas par cas ce qui convient le mieux à vos clusters.

Pour limiter cette règle à tous les ordinateurs hôtes de votre cluster, sous «Host labels», saisissez simplement «cmk/kubernetes:yes» dans le champ «Conditions». Toutefois, si vous souhaitez également créer des règles différentes pour différents 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 y accédez 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. Ce nom peut être défini librement selon vos préférences. Il sert à attribuer un nom unique à tous les objets provenant de ce cluster spécifique. 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. Par exemple, le nom de domaine d'un pod pourrait alors être pod_mycluster_kube-system_svclb-traefik-8bgw7.

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 via laquelle votre serveur API Kubernetes peut être contacté. Le port n’est requis que si le service n’est pas fourni via un hôte virtuel. Saisissez ici l’adresse que vous avez déterminée dans la section Récupérer la ressource de l’API Kubernetes.

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

Activez l’option « Enrich with usage data », sélectionnez « Use data from OpenShift » dans le menu suivant, puis saisissez l’adresse Prometheus API endpoint que vous avez déterminée dans la section « Récupérer la ressource de l’API Prometheus ».

La liste sous « Collect information about…​ » vous permet de sélectionner les objets de votre cluster qui doivent être soumis à la supervision. Cette liste couvre les objets les plus pertinents. Si vous décidez également de soumettre à la supervision l'API Prometheus, veuillez vous reporter à l'aide en ligne de cette option.

Les deux sélections suivantes vous permettent d’affiner davantage les objets à superviser. Si vous ne vous intéressez qu’aux objets de certains espaces de nommage, configurez ce paramètre en conséquence sous « Monitor namespaces ». Vous pouvez ici soit saisir des espaces de nommage individuels à superviser, soit exclure explicitement certains espaces de nommage de la supervision.

L'option « Cluster resource aggregation » vous permet de désigner 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, il existe un risque que les goulots d'étranglement de capacité ne soient pas détectés. Nous excluons donc par défaut les nœuds control-plane et infra du calcul.

En dernier recours, vous pouvez importer ce que l'on appelle des annotations depuis Kubernetes. Dans Checkmk, ces annotations deviennent des étiquettes d'hôte et peuvent ainsi être utilisées comme conditions dans des règles. Utilisez des expressions régulières pour spécifier quelles annotations doivent être importées. Consultez à nouveau l'aide en ligne détaillée à ce stade.

Remarque : l'option « Import all valid annotations » (Importer toutes les annotations) est fournie ici uniquement par souci d'exhaustivité. Nous ne recommandons pas d'importer toutes les annotations en une seule fois, car cela peut créer une très grande quantité 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 pour cet ordinateur hôte. Les premiers services au niveau du cluster apparaîtront immédiatement ici :

Activez maintenant toutes les modifications que vous avez apportées et laissez la gestion dynamique des hôtes faire le travail à partir de maintenant. Cela générera tous les ordinateurs hôtes pour vos objets Kubernetes en très courte période de temps.

Les éditions commerciales de Checkmk sont fournies avec six tableaux de bord intégrés pour Kubernetes. Pour pouvoir exploiter ces tableaux de bord, il est nécessaire d'avoir installé et configuré notre Cluster Collector. Plus précisément, ces 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 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. En cliquant sur le nom d'un cluster, vous accédez au tableau de bord Kubernetes Cluster correspondant au 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 d’OpenShift avec Checkmk prend également en charge l’inventaire matériel/logiciel. Par exemple, dans le tableau de bord des clusters ci-dessus, cliquer sur l’ID du cluster (ici : mycluster) vous mènera à l’inventaire du cluster.

De la même manière, c'est-à-dire dans les autres tableaux de bord via les cases contenant les identifiants des objets, l'inventaire de chaque objet concerné peut être affiché. L'exemple suivant montre l'inventaire matériel/logiciel d'un pod :

Si vous avez utilisé notre fichier YAML par défaut pour créer le compte de service, vous pouvez également le supprimer comme suit :