Kubernetes et Prometheus

Photo by Pixabay from Pexels

TL;DR Prometheus est un ensemble de composants qui permettent de superviser des infrastructures et des applications. Cet article est une introduction à Prometheus. Il présente ses principes ainsi qu'une configuration simple pour Kubernetes.

Concepts clés

Prometheus s'appuie sur des concepts qui peuvent paraitre, au premier abord, à contre-courant. Utilisée de manière régulière, la solution offre vite plusieurs avantages et s'avère particulièrement adaptée aux approches cloud natives. Les concepts clés sont:

  • Une base données spécialisée, interchangeable, qui gère un nombre limité de types de mesures sous la forme de séries temporelles organisées selon des axes faciles à étendre à l'aide d'étiquettes. Les mesures collectées par Prometheus sont labellisées par instance, service, par équipe ou n'importe quelle dimension qui convient à votre besoin.
  • PromQL, un langage de requête qui permet de créer des graphes et des mesures composites facilement et servir de source pour des alertes
  • Un protocole de communication simple basé sur HTTP et qui extrait toutes ses mesures d'un fichier texte
  • Des bibliothèques clientes pour de nombreux clients qui implémentent, pour la plupart, déjà un certain nombre de mesures
  • Un collecteur de mesures ou scraper qui tire les données des systèmes supervisés de façon régulière via un mécanisme dit de poll
  • Des politiques d'alertes et d'agrégation des mesures qui sont stockées et mises en oeuvre sur le serveur Prometheus
  • Une configuration dynamique très facile à intégrer à des services de découverte tels que Kubernetes et Consul ou pour utiliser des labels sur Openstack, AWS, Google ou Azure
  • Une liste d'exporters qui exposent les mesures de dizaines de composants du système aux différentes plateformes, ce à quoi s'ajoutent les produits qui exposent directement leur mesures pour Prometheus.
  • Des composants spécialisés ou tiers pour () gérer les notifications avec Prometheus Alert Manager,` () superviser de l'extérieur avec le Black Box Exporter, () visualiser les données avec Grafana, () la possibilité de collecter des données générées par des programmes qui n'exposent pas de route avec StatsD exporter ou pushgateway, (*) la possibilité de collecter des données à plus long terme avec Cortex ou Thanos.

Prometheus et solutions traditionnelles

Les sujets qui reviennent le plus souvent lorsqu'on implémente Prometheus et qui peuvent paraitre contre-intuitifs sont:

  • Le fait que les mesures soient collectées via des scrapers depuis le serveur et non "poussés" par des agents.
  • Le fait que les exporter soient de simples serveurs HTTP avec des mesures générés sous la forme d'un fichier texte
  • Le fait que le serveur prometheus soit monolithique et génère les alertes

Collecte via des scrapers

C'est sans doute le sujet le plus sensible par ses implications. Le serveur Prometheus doit être situé à portée des cibles qu'il supervise et y accéder via HTTP. Il y a plusieurs moyens de rapprocher et de protéger les cibles en question mais il s'agit d'un fait. Cela implique que la supervision et l'infrastructure sont proches. De manière pratique, Prometheus est le plus souvent sur la même infrastructure que les applications et les composants qu'il supervise. C'est particulièrement le cas avec des containers.

L'intérêt de cette architecture est multiple:

  • l'agent, devenu exporter n'a pas besoin de connaitre quoi que ce soit à propos du serveur de supervision. Le paramétrage de l'application est quasiment inexistant, il suffit généralement que l'application s'enregistre dans un service de découverte comme consul ou, encore plus simple, de poser des labels sur votre infrastructure Cloud
  • Plusieurs serveurs peuvent fonctionner en parallèle ce qui permet de facilement mettre en place de la haute disponibilité ou de mettre à jour prometheus
  • Il est plus facile de coordonner la charge associée à la supervision lorsque c'est le serveur qui est à l'initiative des requêtes

Une "API texte" sur HTTP

Un autre sujet de discussion est l'ensemble des contraintes liées au protocole de collecte des mesures. Le protocole est fixe, basé uniquement sur HTTP. Les mesures suivent également un modèle simple avec un nom de mesure, des labels et une valeur numérique.

Les raisons d'une telle approche sont motivées par la simplicité d'implémentation. Les types de mesure sont éprouvés et créer un exporter pour son application est extrêmement facile, même lorsqu'il n'existe pas de bibliothèque client. Un autre bénéfice est que le modèle de stockage est très efficace. Pour contre-balancer ces limites, il existe des solutions, par exemple:

  • si vous voulez avoir une information "texte" comme une version, vous voudrez l'ajouter aux labels
  • si vous voulez superviser des composants "dont l'état est transitoire" comme des fonctions ou des batchs, vous utiliserez des composants qui collectent les données comme un serveur StatsD ou la Pushgateway

La principale motivation d'une approche où toutes les mesures sont accessibles avec des types standards dans une unique route est que l'ajout d'une nouvelle mesure est immédiatement pris en compte. Il n'y a besoin d'aucune action sur le serveur. Etendre la supervision est donc, là encore, extrêmement simple.

Un serveur monolithique

Le serveur Prometheus est un binaire en go qui contient toutes les fonctions de collecte, de requêtes, d'agrégats et d'alertes. L'inconvénient de cette approche est que les capacités du serveur sont limitées par l'infrastructure sous-jascente. Pour assurer la montée en charge de la solution, il faut partitioner la solution et utiliser des outils complémentaires comme la fédération ou des extensions commne Cortex ou Thanos.

L'avantage de cette approche est que la solution est très simple à mettre en oeuvre.

Quelques autres caractéristiques

Un certains nombre d'autres caractériques sont importantes à noter:

  • Les échanges entre le serveur et les exporter sont limités. Il convient, en cas de besoin de mettre en place des solutions externes comme Consul connect ou Istio pour mettre en oeuvre de la sécurité par exemple.
  • Les alertes sont générées sur le serveur. Cela implique qu'il faut pouvoir sécuriser le serveur. Une approche typique consiste à mettre en place plusieurs serveurs. Pour éviter les vagues de notifications, le serveur associé, typiquement Prometheus AlertManager doit être paramétré pour générer les alertes de maniière intelligente.
  • La solution contient des graphiques par mesure uniquement. Pour mettre en ouvre des tableaux de bord plus avancés il faut de mettre en oeuvre une solution complémentaire telle que Grafana.

Installer Prometheus sur Kubernetes

Il existe plusieurs stratégies pour mettre en oeuvre Prometheus sur Kubernetes. Vous pourrez, par exemple, utiliser Helm ou l'Operator Prometheus. Dans les sections qui suivent, vous trouverez une installation manuelle d'un d'une solutions de supervision. Cela permet de bien comprendre le fonctionnement de l'infrastructure. Un actif essentiel pour comprendre comment réaliser cette installation est le projet kube-prometheus qui regroupe un nombre important de manifests pour installer ces composants. En particulier, vous verrez:

  • L'installation de kube-state-metrics qui expose les mesures sur les composants gérés
  • L'installation de node-exporter qui expose les mesures des instances
  • L'installation et la configuration de Prometheus qui collecte les mesures sur les exporters et les composants qui exposent directement les éléments tels que les Kubelets
  • L'installation de Grafana et d'un rapport type pour visualiser le fonctionnement de Kubernetes

Pour réaliser une configuration complète, vous voudrez ajouter d'autres composants tels que le AlertManager et des intégrations à des composants que que vous pourrez utiliser spécifiquement comme un Ingress Controller, le collecteur des logs ou vos applications

kube-state-metrics

kube-state-metrics expose des mesures pour Prometheus à partir de l'API Kubernetes. Pour installer le composant, s'il n'est pas pris en charge par votre fournisseur, vous pouvez utilisert le contenu du répertoire kube-state-metrics/examples/standard/ comme ci-dessous:

git clone https://github.com/kubernetes/kube-state-metrics.git
cd kube-state-metrics/examples/standard/
kubectl apply -f .

Node-exporter

node-exporter expose les mesures de vos systèmes pour Prometheus. Selon votre configuration, vous voudrez une installation au niveau du système, par exemple avec SystemD. Vous pouvez également, dans ce cas, utiliser le chart Helm pour node-exporter Vous trouverez ci-dessous une procédure pour installer le node-exporter manuellement grace aux manifests disponibles dans coreos/kube-prometheus. Ce projet maintient les scripts pour gérer les composants de l'opérateur Prometheus et il est très intéressant pour comprendre les composants impliqués. Vous pouvez utiliser les manifests associés au node-exporter pour procéder à l'installation comme ci-dessous:

git clone https://github.com/coreos/kube-prometheus.git
cd kube-prometheus/manifests
kubectl create namespace monitoring
kubectl apply -f node-exporter-clusterRole.yaml
kubectl apply -f node-exporter-serviceAccount.yaml
kubectl apply -f node-exporter-clusterRoleBinding.yaml
kubectl apply -f node-exporter-daemonset.yaml
kubectl apply -f node-exporter-service.yaml

Note: la configuration utilisée s'appuie sur kube-rbac-proxy et nécessite d'utiliser le compte de service de Prometheus pour se connecter.

Installer et configurer Prometheus

La configuration Prometheus est volontairement simplifiée pour illustrer le principe. Elle est disponible dans le répertoire blog/kubernetes-prometheus du projet easyteam-fr/side-effects

Pour l'installer, procédez comme suit:

git clone https://github.com/easyteam-fr/side-effects.git
cd side-effects/blog/kubernetes-prometheus
kubectl apply -k .

La projet contient:

  • Un compte de service associé à un rôle pour accéder à l'API Kubernetes
  • Une configmap générée par Kustomize qui contient le paramétrage de Prometheus
  • Un deployment et un service qui servent Prometheus

La partie intéressante est la configuration de Prometheus. La section ci-dessous définit la connexion à kube-state-metrics. Pour cela, elle contient un enregistrement statique vers le service associé pour collecter les différentes mesures de consommation:

scrape_configs:
  - job_name: kube-state-metrics
    static_configs:
      - targets:
          - kube-state-metrics.kube-system.svc:8080

  - job_name: kube-state-telemetry
    static_configs:
      - targets:
          - kube-state-metrics.kube-system.svc:8081

La seconde section permet d'enregistrer les node-exporter qui collectent les mesure système. Celle-ci est un peu plus évoluée, elle définit:

  • le token et le certificat pour se connecter à kube-rbac-proxy qui permettent de gérer la sécurité d'accès.
  • le paramétrage de la connexion à travers le label __address__ qui est positionné avec l'adresse IP sur le port 9100
  - job_name: kubernetes-nodes
    scheme: https
    tls_config:
      ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
      insecure_skip_verify: true
    bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
    kubernetes_sd_configs:
    - role: node
    relabel_configs:
    - action: labelmap
      regex: __meta_kubernetes_node_label_(.+)
    - source_labels: [__meta_kubernetes_node_address_InternalIP]
      regex: (.+)
      target_label: __address__
      replacement: ${1}:9100

Pour tester la connexion, vous créerez une connection avec le service associé à Prometheus comme ci-dessous et vous lancerez une connexion sur localhost:9090

kubectl port-forward -n monitoring svc/prometheus 9090:9090

La console s'affiche comme ci-dessous:

Cibles Prometheus

Rapports Grafana

La configuration contient également une instance de Grafana. La datasource est enregistrée; elle référence l'installation de Prometheus.

Pour se connecter, il faut utiliser la commande ci-dessous et se connecter à localhost:3000 :

kubectl port-forward -n monitoring svc/grafana 3000:3000

On pourra ensuite créer ou installer le rapport qui correspond à nos besoins. Pour le node-exporter, on pourra par exemple installer Node Exporter Server Metrics. Vous pourrez alors accéder ou générer les graphes qui vous intéressent comme ci-dessous:

Connexion Grafana et Prometheus

Pour aller plus loin

Retenez que la configuration de Prometheus est simple. Une fois que vous avez effectué le paramétrage, elle est installée en quelques secondes et s'étend avec votre cluster. Avec Grafana, ils forment un ensemble facile à utiliser dans vos projets.

Cet article est une introduction détaillée mais reste une introduction. Pour des outils plus évolués, vous voudrez mettre en place le metrics-server comme expliqué dans Kubernetes Metrics Server puis installer Mesures et tableau de bord Kubernetes

Et surtout, n'hésitez pas à étudier les projets référencés dans ci-dessus; ce sont des mines d'informations !

Easyteam DevOps

Easyteam DevOps