Générer des rapports personnalisés à l'aide de l'opérateur Metering

Operator Metering est un outil de facturation et de création de rapports qui permet de définir l'utilisation des ressources dans un cluster Kubernetes. Les administrateurs de clusters peuvent planifier la génération de rapports basés sur l'historique des données d'utilisation par pod, espace de noms ou cluster. 

De nombreuses requêtes de rapport déjà configurées sont proposées lorsque l'opérateur Metering est installé. Par exemple, si un administrateur souhaite mesurer l'utilisation du processeur (ou de la mémoire) pour les nœuds du cluster (ou les pods), il lui suffit d'installer l'opérateur Metering et d'écrire une ressource personnalisée Report pour générer un rapport (par mois, heure, etc.).

Cas d'utilisation

Certaines exigences sont récurrentes chez les clients. 

1. Parfois, les nœuds de calcul d'un cluster OpenShift pour les environnements hors production ne s'exécutent pas de façon permanente (par exemple, un administrateur souhaite désactiver quelques nœuds de calcul en fonction de la capacité disponible ou pendant les week-ends). Dans ce cas, le client va chercher à mesurer l'utilisation du processeur (ou de la mémoire) d'un nœud sur une base mensuelle, afin que l'équipe chargée de l'infrastructure facture l'utilisation réelle des nœuds aux utilisateurs.
2. Le client suit un modèle de déploiement dans le cadre duquel il déploie un cluster OpenShift dédié pour des équipes spécifiques. Il peut installer l'opérateur Metering et obtenir des informations sur l'utilisation des nœuds. Il veut cependant indiquer dans le rapport de facturation l'équipe (ou le service) qui utilise les nœuds de calcul. Ce cas d'utilisation peut également s'étendre aux clusters dédiés partagés qui comportent des nœuds « étiquetés », chaque étiquette identifiant la charge de travail du service ou de l'équipe qui s'exécute sur les nœuds.
3. Dans un cluster partagé, l'équipe d'exploitation souhaite facturer la durée d'exécution des pods aux équipes (qu'il s'agisse de l'utilisation du processeur ou de la mémoire). Encore une fois, le but est de simplifier le rapport pour indiquer l'équipe (ou le service) à laquelle les pods appartiennent.

Ces exigences conduisent à la création de ressources personnalisées dans le cluster. C'est ce que nous allons apprendre à faire facilement dans cet article. Veuillez noter que nous ne verrons pas comment installer l'opérateur Metering. Si besoin, consultez la documentation relative à l'installation ici. Pour en savoir plus sur l'utilisation des rapports prêts à l'emploi, reportez-vous à la documentation ici.

Fonctionnement de l'opérateur Metering

Avant de passer à la création de ressources personnalisées pour nos cas d'utilisation précédents, il faut comprendre le fonctionnement de l'outil OpenShift Metering. Au total, l'opérateur Metering crée six ressources personnalisées une fois qu'il est installé. Les trois suivantes nécessitent un peu plus d'explications. 

1. ReportDataSources (rds) : le mécanisme rds permet de définir les données disponibles qui peuvent être utilisées par les ressources personnalisées ReportQuery (rq) ou Report. Il permet également de récupérer des données issues de plusieurs sources. Dans OpenShift, les données sont extraites à l'aide de Prometheus et de la ressource personnalisée ReportQuery. 
2. ReportQuery (rq) : la ressource rq contient les requêtes SQL qui permettent d'analyser les données stockées avec rds. Si un objet rq est référencé par un objet Report, l'objet rq gère également les éléments à prendre en compte lors de l'exécution du rapport. S'il est référencé par un objet rds, l'objet rq s'appuie sur la requête rendue pour indiquer à Metering de créer une vue dans les tables Presto (créées dans le cadre de l'installation de l'outil).
3. Report : cette ressource personnalisée base la génération de rapports sur la ressource ReportQuery configurée. Il s'agit de la principale ressource avec laquelle un utilisateur final de l'opérateur Metering interagit. Elle peut être configurée pour s'exécuter selon un calendrier.

De nombreuses ressources rds et rq déjà configurées sont disponibles. Puisque nous nous intéressons à la mesure au niveau du nœud, voyons les ressources qu'il est nécessaire de comprendre pour écrire des requêtes personnalisées. Exécutons la commande suivante dans le projet « openshift-metering » :

Pour mesurer l'utilisation du processeur, nous devons nous concentrer sur deux ressources rds : « node-capacity-cpu-cores » et « node-cpu-capacity-raw ». Commençons par node-capacity-cpu-cores et exécutons la commande suivante pour observer la manière dont les données sont collectées à l'aide de Prometheus :

Nous pouvons voir la requête Prometheus utilisée pour extraire des données de Prometheus et les stocker dans des tables Presto. Exécutons la même requête dans la console de mesure d'OpenShift et observons le résultat. Nous disposons d'un cluster OpenShift qui comprend 2 nœuds de calcul (chaque nœud possède 16 cœurs) et 3 nœuds de gestion (chacun possède 8 cœurs). La dernière colonne, « value », indique les cœurs attribués aux nœuds.

Les données sont donc collectées et stockées dans les tables Presto. Intéressons-nous maintenant à quelques ressources personnalisées reportquery (rq) :

Ici, nous devons nous concentrer sur les ressources rqs « node-cpu-capacity » et « node-cpu-capacity-raw ». Si nous détaillons ces ressources, nous pouvons comprendre qu'elles permettent de calculer des données (par exemple, la durée d'utilisation du nœud ou le nombre de processeurs qui lui sont attribués) et de les agréger. 

Le diagramme ci-dessous montre la manière dont les deux ressources rds et les deux ressources rqs sont connectées.

node-cpu-capacity (rq) utilise node-cpu-capacity-raw (rds) qui utilise node-cpu-capacity-raw (rq) qui utilise node-capacity-cpu-cores (rds)

Personnalisation des rapports

Voyons comment écrire des ressources rds et rq personnalisées. Nous devons d'abord modifier la requête Prometheus pour indiquer si le nœud fonctionne comme un nœud de gestion ou de calcul, puis ajouter une étiquette appropriée qui identifie l'équipe à laquelle le nœud appartient. L'indicateur de mesure Prometheus « kube_node_role » contient des données sur le rôle du nœud (de gestion ou de calcul). Observons la colonne « role » :

L'indicateur de mesure Prometheus « kube_node_labels » capture toutes les étiquettes appliquées à un nœud en tant que « label_ ». Par exemple, si nous appliquons une étiquette avec la clé « node_lob » à un nœud, l'indicateur Prometheus capture les données sous la forme « label_node_lob ». 

Il ne nous reste plus qu'à modifier la requête d'origine à l'aide de ces quelques requêtes Prometheus supplémentaires pour obtenir des données pertinentes. Voici cette requête personnalisée :

((kube_node_status_capacity_cpu_cores * on(node) group_left(provider_id) max(kube_node_info) by (node, provider_id)) * on(node) group_left (role) kube_node_role{role='worker'}) * on(node) group_right(provider_id, role) kube_node_labels

Exécutons cette requête sur la console de mesure d'OpenShift et vérifions que nous avons obtenu les informations relatives à l'étiquette (node_lob) et au rôle. Dans les résultats ci-dessous, nous pouvons voir label_node_lob et role (les informations sur le rôle sont masquées, car la requête génère de nombreuses colonnes) :

Écrivons maintenant quatre ressources personnalisées, chargées ici pour plus de simplicité :

1. rds-custom-node-capacity-cpu-cores.yaml : définit la requête Prometheus.
2. rq-custom-node-cpu-capacity-raw.yaml : fait référence aux ressources rds ci-dessus et calcule des données brutes.
3. rds-custom-node-cpu-capacity-raw.yaml : fait référence aux ressources rq ci-dessus et crée une vue dans Presto.
4. rq-custom-node-cpu-capacity-with-cpus-labels.yaml : fait référence aux ressources rds mentionnées dans la ressource 3 et effectue un calcul à partir des données de début et de fin d'entrée. Il s'agit également du fichier dans lequel nous récupérons les colonnes role et node_label.

Une fois que ces fichiers yaml sont créés, il faut accéder au projet openshift-metering et exécuter les commandes suivantes :

Pour terminer, il suffit d'écrire un objet personnalisé Report qui fait référence au dernier objet rq créé ci-dessus. Il est possible de s'inspirer de l'exemple suivant. Le rapport ci-dessous s'exécute immédiatement et affiche les données disponibles entre le 15 et le 30 septembre.

Une fois ce rapport généré, le fichier (au format .csv ou .json) peut être téléchargé via cette URL (la variable DOMAIN_NAME doit être adaptée) :

https://metering-openshift-metering.DOMAIN_NAME/api/v1/reports/get?name=custom-role-node-cpu-capacity-hourly&namespace=openshift-metering&format=csv

L'instantané CSV ci-dessous montre les données capturées avec les deux colonnes role et node_lob. La valeur de la colonne « node_capacity_cpu_core_seconds » doit être divisée par « node_capacity_cpu_cores » pour obtenir la durée d'exécution du nœud en secondes :

Résumé

L'opérateur Metering est un outil intéressant qui peut s'exécuter sur des clusters OpenShift, quel que soit l'environnement. Il fournit un cadre extensible qui permet aux clients d'écrire leurs propres ressources personnalisées pour créer des rapports adaptés à leurs besoins. Tout le code utilisé ci-dessus est disponible ici.