À propos du projet
kube-state-metrics (KSM) est un service qui écoute le serveur d'API Kubernetes et génère des métriques sur l'état des objets du cluster tels que les déploiements, les nœuds et les pods. Plutôt que de surveiller la santé des composants Kubernetes individuels, il rend compte des objets à l'intérieur du cluster. Les métriques sont exposées en texte brut sur le point de terminaison HTTP /metrics (port par défaut 8080) et sont destinées à Prometheus ou à des collecteurs compatibles ; le point de terminaison reflète l'état actuel du cluster, de sorte que les objets supprimés en disparaissent.
Philosophie de conception : KSM génère des métriques à partir des objets de l'API Kubernetes sans modification, de sorte que ses fonctionnalités partagent le niveau de stabilité des objets d'API sous-jacents. Il expose des données brutes, non modifiées, plutôt que d'appliquer des heuristiques de style kubectl, laissant l'interprétation aux utilisateurs. Les métriques basées sur des API alpha sont exclues des garanties de stabilité.
Capacités clés décrites dans le README :
- Documentation des métriques dans le répertoire docs, ainsi que des métriques d'état de ressources personnalisées (fonctionnalité gelée au profit de resource-state-metrics).
- Gestion des étiquettes : les noms d'étiquettes Kubernetes sont convertis en noms compatibles avec Prometheus (par exemple app.kubernetes.io/name devient label_app_kubernetes_io_name), avec des suffixes _conflictN automatiques lorsque les conversions entrent en collision.
- Les listes d'autorisation/refus prennent en charge les expressions régulières ECMAScript, y compris les lookarounds, avec une évaluation limitée à une minute.
- Métriques propres sur un hôte/port de télémétrie distinct (par défaut 8081), incluant des compteurs de succès et d'erreurs de list/watch, des histogrammes de durée des requêtes HTTP, les informations de build, l'ordinal de shard et le nombre total de shards, ainsi que le hachage du fichier de configuration et l'état de rechargement.
- Conseils de dimensionnement : environ 250 Mio de mémoire et 0,1 cœur en règle générale ; des limites de CPU faibles peuvent provoquer une accumulation de file d'attente et une utilisation accrue de la mémoire. Des chiffres de latence issus d'un test de mise à l'échelle à 100 nœuds sont fournis (Perc50 ~260 ms, Perc90 ~475 ms, Perc99 ~907 ms).
- Sharding horizontal via --shard et --total-shards, en utilisant un md5 de l'UID de l'objet modulo le nombre total de shards ; sharding automatisé dans un StatefulSet via --pod et --pod-namespace (expérimental) ; sharding basé sur un déploiement avec des index de shard explicites ; et sharding par daemonset pour les métriques de pods via --node, avec --track-unscheduled-pods pour les pods non assignés.
- Filtrage des ressources sur /metrics à l'aide des paramètres de requête resources et exclude_resources, exclude étant prioritaire.
- Points de terminaison de santé : /healthz et /livez sur le port principal, /readyz sur le port de télémétrie.
Installation et utilisation : installer via go get k8s.io/kube-state-metrics/v2, construire un conteneur avec make container, et déployer avec kubectl apply -f examples/standard. La pile kube-prometheus inclut déjà KSM comme composant. Les utilisateurs de GKE peuvent avoir besoin d'une liaison cluster-admin en raison de permissions de rôle strictes. Le README compare également KSM à metrics-server : metrics-server fournit des métriques de ressources agrégées depuis Kubelet via l'API Metrics, tandis que KSM génère de nouvelles métriques à partir de l'état des objets et conserve un instantané en mémoire. Ni l'un ni l'autre n'exporte lui-même des métriques vers des destinations tierces.
Comments
0 Rating appears after 10 ratings
Sign in to join the discussion.