metrics server

Serveur de métriques Kubernetes

Metrics Server est une source évolutive et efficace de métriques de ressources de conteneur pour les pipelines de mise à l'échelle automatique intégrés à Kubernetes.

Metrics Server collecte les métriques de ressources des Kubelets et les expose dans l'apiserver Kubernetes via l'API Metrics pour une utilisation par l'autoscaler horizontal de pods et l'autoscaler vertical de pods. L'API Metrics est également accessible via kubectl top , ce qui facilite le débogage des pipelines de mise à l'échelle automatique.

Prudence

Metrics Server est destiné uniquement à des fins de mise à l'échelle automatique. Par exemple, ne l’utilisez pas pour transmettre des métriques à des solutions de surveillance ou comme source de métriques de solutions de surveillance. Dans de tels cas, veuillez collecter directement les métriques du point de terminaison Kubelet /metrics/resource .

Le serveur de métriques propose :

• Un déploiement unique qui fonctionne sur la plupart des clusters (voir Exigences)
• Mise à l'échelle automatique rapide, collecte de métriques toutes les 15 secondes.
• Efficacité des ressources, en utilisant 1 milicœur de processeur et 2 Mo de mémoire pour chaque nœud d'un cluster.
• Prise en charge évolutive jusqu'à 5 000 clusters de nœuds.

Cas d'utilisation

Vous pouvez utiliser Metrics Server pour :

• Mise à l'échelle horizontale basée sur le processeur/la mémoire (en savoir plus sur la mise à l'échelle horizontale)
• Ajustement/suggestion automatique des ressources nécessaires aux conteneurs (en savoir plus sur l'autoscaling vertical)

N'utilisez pas Metrics Server lorsque vous avez besoin :

• Clusters non Kubernetes
• Une source précise de mesures d’utilisation des ressources
• Mise à l'échelle horizontale basée sur d'autres ressources que CPU/Mémoire

Pour les cas d'utilisation non pris en charge, consultez des solutions de surveillance complètes comme Prometheus.

Exigences

Metrics Server a des exigences spécifiques pour la configuration du cluster et du réseau. Ces exigences ne sont pas celles par défaut pour toutes les distributions de cluster. Veuillez vous assurer que votre distribution de cluster prend en charge ces exigences avant d'utiliser Metrics Server :

• Le kube-apiserver doit activer une couche d'agrégation.
• Les nœuds doivent avoir l’authentification et l’autorisation Webhook activées.
• Le certificat Kubelet doit être signé par l'autorité de certification du cluster (ou désactiver la validation du certificat en transmettant --kubelet-insecure-tls au serveur Metrics)
• Le runtime du conteneur doit implémenter un RPC de métriques de conteneur (ou prendre en charge cAdvisor)
• Le réseau doit prendre en charge les communications suivantes :
  • Plan de contrôle vers Metrics Server. Le nœud du plan de contrôle doit atteindre l'adresse IP du pod et le port 10250 de Metrics Server (ou l'adresse IP du nœud et le port personnalisé si hostNetwork est activé). En savoir plus sur la communication entre le plan de contrôle et le nœud.
  • Metrics Server vers Kubelet sur tous les nœuds. Le serveur de métriques doit atteindre l'adresse du nœud et le port Kubelet. Les adresses et les ports sont configurés dans Kubelet et publiés dans le cadre de l'objet Node. Adresses dans .status.addresses et port dans le champ .status.daemonEndpoints.kubeletEndpoint.port (par défaut 10250). Metrics Server choisira l'adresse du premier nœud en fonction de la liste fournie par l'indicateur de ligne de commande kubelet-preferred-address-types ( InternalIP,ExternalIP,Hostname dans les manifestes).

Installation

Metrics Server peut être installé soit directement à partir du manifeste YAML, soit via la charte Helm officielle. Pour installer la dernière version de Metrics Server à partir du manifeste composants.yaml , exécutez la commande suivante.

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

Les instructions d'installation des versions précédentes sont disponibles dans les versions de Metrics Server.

Matrice de compatibilité

Serveur de métriques	Groupe/version de l'API de métriques	Version Kubernetes prise en charge
0.7.x	metrics.k8s.io/v1beta1	1.19+
0.6.x	metrics.k8s.io/v1beta1	1.19+
0.5.x	metrics.k8s.io/v1beta1	*1,8+
0.4.x	metrics.k8s.io/v1beta1	*1,8+
0.3.x	metrics.k8s.io/v1beta1	1.8-1.21

*Les versions Kubernetes inférieures à la v1.16 nécessitent de transmettre l'indicateur de ligne de commande --authorization-always-allow-paths=/livez,/readyz

Haute disponibilité

Metrics Server peut être installé en mode haute disponibilité directement à partir d'un manifeste YAML ou via la charte Helm officielle en définissant la valeur replicas supérieure à 1 . Pour installer la dernière version de Metrics Server en mode haute disponibilité à partir du manifeste high-availability.yaml , exécutez la commande suivante.

Sur Kubernetes v1.21+ :

 kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/high-availability-1.21+.yaml

Sur Kubernetes v1.19-1.21 :

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/high-availability.yaml

Note

Cette configuration nécessite de disposer d'un cluster avec au moins 2 nœuds sur lesquels Metrics Server peut être planifié.

De plus, pour maximiser l'efficacité de cette configuration hautement disponible, il est recommandé d'ajouter l'indicateur CLI --enable-aggregator-routing=true au kube-apiserver afin que les requêtes envoyées à Metrics Server soient équilibrées en charge entre les 2 instances.

Tableau de barre

La carte Helm est conservée en tant que composant supplémentaire dans ce référentiel et publiée dans un référentiel de cartes sauvegardé sur la branche gh-pages . Une nouvelle version du graphique sera publiée pour chaque version de Metrics Server et pourra également être publiée indépendamment si nécessaire. Le graphique sur la branche master ne doit pas être référencé directement car il peut contenir des modifications depuis sa dernière publication. Pour afficher le code du graphique, utilisez la balise de version du graphique.

Contexte de sécurité

Metrics Server nécessite la fonctionnalité CAP_NET_BIND_SERVICE afin de se lier à un port privilégié en tant que non root. Si vous exécutez Metrics Server dans un environnement qui utilise des PSS ou d'autres mécanismes pour restreindre les fonctionnalités des pods, assurez-vous que Metrics Server est autorisé à utiliser cette fonctionnalité. Cela s'applique même si vous utilisez l'indicateur --secure-port pour modifier le port que Metrics Server lie à un port non privilégié.

Mise à l'échelle

À partir de la version 0.5.0, Metrics Server est livré avec des requêtes de ressources par défaut qui devraient garantir de bonnes performances pour la plupart des configurations de cluster jusqu'à 100 nœuds :

• 100 millions de cœurs de processeur
• 200 Mo de mémoire

L'utilisation des ressources de Metrics Server dépend de plusieurs dimensions indépendantes, créant ainsi une enveloppe d'évolutivité. La configuration par défaut de Metrics Server doit fonctionner dans les clusters qui ne dépassent aucun des seuils répertoriés ci-dessous :

Quantité	Seuil d'espace de noms	Seuil de cluster
#Nœuds	n / A	100
#Pods par nœud	70	70
#Déploiements avec des HPA	100	100

Les ressources peuvent être ajustées proportionnellement en fonction du nombre de nœuds dans le cluster. Pour les clusters de plus de 100 nœuds, allouez en plus :

• 1 million de cœurs par nœud
• 2 Mo de mémoire par nœud

Vous pouvez utiliser la même approche pour réduire les demandes de ressources, mais il existe une limite où cela peut avoir un impact sur d'autres dimensions d'évolutivité, comme le nombre maximum de pods par nœud.

Configuration

En fonction de la configuration de votre cluster, vous devrez peut-être également modifier les indicateurs transmis au conteneur Metrics Server. Indicateurs les plus utiles :

• --kubelet-preferred-address-types - La priorité des types d'adresses de nœud utilisés lors de la détermination d'une adresse pour la connexion à un nœud particulier (par défaut [Hostname,InternalDNS,InternalIP,ExternalDNS,ExternalIP])
• --kubelet-insecure-tls - Ne vérifie pas l'autorité de certification des certificats de service présentés par Kubelets. À des fins de test uniquement.
• --requestheader-client-ca-file - Spécifiez un ensemble de certificats racine pour vérifier les certificats clients sur les demandes entrantes.
• --node-selector -Peut terminer pour extraire les métriques des nœuds spécifiés en fonction des étiquettes

Vous pouvez obtenir une liste complète des indicateurs de configuration de Metrics Server en exécutant :

docker run --rm registry.k8s.io/metrics-server/metrics-server:v0.7.0 --help

Conception

Metrics Server est un composant du pipeline de métriques principal décrit dans l'architecture de surveillance Kubernetes.

Pour plus d'informations, voir :

• Conception d'API de métriques
• Conception du serveur de métriques

Vous avez une question ?

Avant de publier un problème, consultez d'abord la foire aux questions et les problèmes connus.

Communauté, discussion, contribution et soutien

Découvrez comment interagir avec la communauté Kubernetes sur la page de la communauté.

Vous pouvez contacter les responsables de ce projet à l'adresse :

• Chaîne Slack
• Liste de diffusion

Ce projet est maintenu par SIG Instrumentation

Code de conduite

La participation à la communauté Kubernetes est régie par le Code de conduite Kubernetes.