Pourquoi ne puis-je pas collecter des métriques à partir de conteneurs, de pods ou de nœuds à l'aide de Metrics Server dans Amazon EKS ?
Date de la dernière mise à jour : 23/01/2020
Je ne peux pas collecter de métriques à partir de conteneurs, de pods ou de nœuds avec Metrics Server dans mon cluster Amazon Elastic Kubernetes Service (Amazon EKS).
Brève description
Dans Amazon EKS, Metrics Server n'est pas installé par défaut. Si vous venez de créer votre cluster et que vous ne pouvez pas collecter de métriques à partir de conteneurs, de pods ou de nœuds à l'aide de Metrics Server, vérifiez que vous avez déployé l'application Metrics Server sur votre cluster.
Si vous ne parvenez toujours pas à collecter de métriques avec Metrics Server, suivez les étapes décrites dans les sections suivantes :
- Vérifier que vous pouvez récupérer des métriques à partir des nœuds et des pods de votre cluster.
- Vérifier que l'APIService est disponible et peut gérer les demandes.
- Vérifier les problèmes courants concernant GitHub.
- Vérifier votre Horizontal Pod Autoscaler (HPA) et vos demandes de ressources d'application si les métriques s'affichent en tant que <unknown>.
Remarque : Metrics Server n'est pas conçu pour la surveillance à long terme des performances des applications et des clusters. Pour une surveillance à long terme, consultez Gestion des ressources pour les conteneurs.
Résolution
Vérifier que vous pouvez récupérer des métriques à partir des nœuds et des pods de votre cluster
Pour rechercher les erreurs entre le serveur d'API et Metrics Server, exécutez les commandes suivantes pour extraire les métriques des nœuds et des pods de votre cluster :
$ kubectl top nodes
$ kubectl top pods
Si vous ne recevez pas d'erreur de l'une ou l'autre des commandes, suivez les étapes de la section Vérifier que l'APIService est disponible et peut gérer les demandes.
Si vous avez reçu une erreur, suivez les étapes de l'une des sections suivantes en fonction de l'erreur que vous avez reçue :
- Error from server (Forbidden)
- Error from server (ServiceUnavailable)
- Client.Timeout exceeded while awaiting headers
- connection refused
Error from server (Forbidden)
Ce message d'erreur indique que vous rencontrez un problème avec l'autorisation RBAC. Pour résoudre cette erreur, confirmez les éléments suivants :
- Le ServiceAccount est correctement attaché au déploiement.
- Les RôlesDeCluster/Rôle et LiaisionsdeRôleDeCluster/LiaisionsDeRôle utilisent les autorisations RBAC adéquates pour Metrics Server.
Si vous accédez à votre cluster via un rôle défini dans le fichier ConfigMap aws-auth, vérifiez que vous avez défini le champ nomd'utilisateur et le mappage.
1. Pour décrire le fichier ConfigMap aws-auth exécutez la commande suivante :
$ kubectl describe -n kube-system configmap aws-auth
2. Vérifiez que le champ username (nom d'utilisateur) a été défini pour le rôle accédant au cluster. Consultez l'exemple suivant :
Name: aws-auth
Namespace: kube-system
Labels: <none>
Annotations: <none>
Data
====
mapRoles:
----
...
-
groups:
- system:masters
rolearn: arn:aws:iam::123456789123:role/kubernetes-devops
username: devops:{{SessionName}} # Ensure this has been specified.
Error from server (ServiceUnavailable)
Pour rechercher un problème avec la configuration de l'application de service Metrics Server dans votre cluster, exécutez la commande suivante :
$ kubectl describe apiservices v1beta1.metrics.k8s.io
Le résultat ressemble à ce qui suit :
Name: v1beta1.metrics.k8s.io
Namespace:
Labels: app=metrics-server
...
API Version: apiregistration.k8s.io/v1
Kind: APIService
Spec:
Group: metrics.k8s.io
Group Priority Minimum: 100
Insecure Skip TLS Verify: true
Service:
Name: metrics-server
Namespace: metrics
...
Status:
Conditions:
Last Transition Time: 2020-01-09T13:57:23Z
Message: all checks passed
Reason: Passed
Status: True
Type: Available
Events: <none>
Si le service Metrics Server est disponible et transmet les contrôles, Status (État) est défini sur True (Vrai).
Si votre problème n'a toujours pas été résolu, même si Status (État) est défini sur True (Vrai), suivez les étapes de la section Vérifier que l'APIService est disponible et peut gérer les demandes.
Si Status (État) est défini sur False (Faux), recherchez le code du motif associé et le message de condition lisible par l'utilisateur dans le résultat. Consultez l'exemple suivant d'échec d'un APIService :
...
Status:
Conditions:
Last Transition Time: 2020-01-09T14:40:28Z
Message: no response from https://10.0.35.231:443: Get https://10.0.35.231:443: dial tcp 10.0.35.231:443: connect: connection refused
Reason: FailedDiscoveryCheck
Status: False
Type: Available
Si le motif n'est pas FailedDiscoveryCheck, suivez les étapes de la section Autres motifs d'échec de la condition APIServer.
Si le code de motif est FailedDiscoveryCheck, le service Metrics Server est disponible et les pods sont en cours d'exécution. Le serveur APIServer de Kubernetes renvoie une erreur lorsqu'il essaie d'atteindre le point de terminaison Metrics Server.
Si le message de conditions APIServer contient l'erreur « Client.Timeout exceeded while awaiting headers », suivez les étapes de la section Résolution de l'erreur « Client.Timeout exceeded while awaiting headers ».
Si le message de conditions APIServer contient l'erreur « connection refused », suivez les étapes de la section Résoudre l'erreur « connection refused ».
Résoudre l'erreur « Client.Timeout exceeded while awaiting headers »
Ce message d'erreur sur l'APIService indique qu'un groupe de sécurité ou une liste de contrôle d'accès (ACL) réseau n'est pas configuré correctement, ce qui empêche l'accès aux pods metrics-server. Consultez l'exemple suivant :
no response from https://10.0.35.231:443: Get https://10.0.35.231:443: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
Pour résoudre cette erreur, vérifiez que vos groupes de sécurité respectent les exigences de trafic minimumpour Amazon EKS.
Résoudre l'erreur « connection refused »
Cette erreur dans le message APIServer indique que le conteneur écoute sur le mauvais port. Consultez l'exemple suivant :
no response from https://10.0.35.231:443: Get https://10.0.35.231:443: dial tcp 10.0.35.231:443: connect: connection refused
Pour résoudre cette erreur, exécutez la commande suivante afin de confirmer que les valeurs des ports, del'image et de la commande sont correctes dans le déploiement metrics-server :
$ kubectl describe deployment metrics-server -n metrics
Le résultat ressemble à ce qui suit :
Name: metrics-server
Namespace: metrics
CreationTimestamp: Wed, 08 Jan 2020 11:48:45 +0200
Labels: app=metrics-server
...
Containers:
metrics-server:
Image: gcr.io/google_containers/metrics-server-amd64:v0.3.6
Port: 443/TCP
Command:
- /metrics-server
- --logtostderr
- --secure-port=443
...
Remarque : les valeurs Commande et Image peuvent varier en fonction de la façon dont Metrics Server a été déployé et de l'emplacement où les images sont stockées. Si la commande contient le paramètre --secure-port, le port (443/TCP, dans l'exemple précédent) exposé par le pod doit correspondre à ce paramètre. Si la commande ne contient pas le paramètre --security-port, le port par défaut est le port 443.
Autres motifs d'échec de la condition APIServer
Si vous recevez l'un des codes de motif suivants pour l'APIService, effectuez une action en fonction du message d'erreur associé : ServiceNotFound, ServiceAccessError, ServicePortError, EndpointsNotFound, EndpointsAccessError, MissingEndpoints.
1. Pour obtenir des informations sur le service avec l'erreur, exécutez la commande suivante :
$ kubectl get service
Dans le résultat, vérifiez que le service Kubernetes a les mêmes nom et espace de noms que ceux définis dans APIService.Spec.Service et vérifiez que le port est défini sur 443/TCP. Consultez l'exemple suivant :
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
metrics-server ClusterIP 172.20.172.133 <none> 443/TCP 65m
2. Pour répertorier les points de terminaison, exécutez la commande suivante :
$ kubectl get endpoints metrics-server
Dans le résultat, vérifiez que vous avez au moins un point de terminaison pour le service metrics-server :
NAME ENDPOINTS AGE
metrics-server 10.0.35.231:443 76m
3. Pour confirmer que le déploiement est présent et que les étiquettes correspondent à celles du service metrics-server, exécutez la commande suivante :
$ kubectl describe deploy metrics-server -n metrics
Dans le résultat, vérifiez que le déploiement comporte au moins un réplica :
Name: metrics-server
Namespace: metrics
CreationTimestamp: Wed, 08 Jan 2020 11:48:45 +0200
Labels: app=metrics-server
release=metrics-server
...
Selector: app=metrics-server,release=metrics-server
Replicas: 1 desired | 1 updated | 1 total | 1 available | 0 unavailable
...
Pod Template:
Labels: app=metrics-server
release=metrics-server
Service Account: metrics-server
Containers:
metrics-server:
Image: gcr.io/google_containers/metrics-server-amd64:v0.3.6
...
Si vous ne pouvez toujours pas collecter des métriques avec Metrics Server, suivez les étapes de la section Vérifier que l'APIService est disponible et peut gérer les demandes.
Vérifier que l'APIService est disponible et peut gérer les demandes
Pour extraire les journaux de vos pods Metrics Server, exécutez la commande suivante :
$ kubectl logs -n <namespace> -l app=metrics-server
Par exemple, les journaux d'erreurs dans metrics-server commencent par un E :
E0610 23:13:28.247604 1 reststorage.go:98] unable to fetch pod metrics for pod default/php-apache-b5f58cc5f-nv8sz: no metrics known for pod "default/php-apache-b5f58cc5f-nv8sz"
E0610 23:13:43.260069 1 reststorage.go:98] unable to fetch pod metrics for pod default/php-apache-b5f58cc5f-nv8sz: no metrics known for pod "default/php-apache-b5f58cc5f-nv8sz"
E0610 23:16:13.346070 1 reststorage.go:98] unable to fetch pod metrics for pod default/php-apache-b5f58cc5f-cj67b: no metrics known for pod "default/php-apache-b5f58cc5f-cj67b"
E0610 23:16:13.346087 1 reststorage.go:98] unable to fetch pod metrics for pod default/php-apache-b5f58cc5f-sqc6l: no metrics known for pod "default/php-apache-b5f58cc5f-sqc6l"
E0610 23:16:13.346091 1 reststorage.go:98] unable to fetch pod metrics for pod default/php-apache-b5f58cc5f-4cpwk: no metrics known for pod "default/php-apache-b5f58cc5f-4cpwk"
Les journaux d'erreurs signalés par Metrics Server indiquent un problème de configuration sur la commande de déploiement Metrics Server ou un bogue avec le conteneur Metrics Server lui-même. Si le message d'erreur n'est pas évident ou si vous pensez qu'il s'agit d'un bogue et que vous ne pouvez toujours pas collecter des métriques avec Metrics Server, suivez les étapes de la section Vérifier les problèmes courants concernant GitHub.
Vérifier les problèmes courants concernant GitHub
Si vous ne pouvez toujours pas collecter des métriques à partir de conteneurs, de pods ou de nœuds, vérifiez les problèmes courants concernant GitHub avec Metrics Server.
Vérifier les métriques inconnues de vos demandes de ressources HPA et d'application
1. Pour vérifier la configuration HPA, exécutez la commande suivante :
$ kubectl get hpa -n namespace 2048-deployment
Remarque : remplacez namespace et 2048-deployment par les valeurs de configuration HPA pour votre application.
Vous pouvez voir <unknown> dans la colonne Cibles du résultat. Consultez l'exemple suivant :
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
2048-deployment Deployment/2048-deployment <unknown>/80% 1 2 2 10s
2. Patientez plusieurs minutes, puis répétez la commande à partir de l'étape 1.
Si vous recevez toujours l'erreur <unknown>, exécutez la commande suivante :
$ kubectl describe hpa -n <namespace> 2048-deployment
À présent, consultez la section Événements du résultat pour plus d'informations :
Name: 2048-deployment
Namespace: 2048-game
...
Metrics: ( current / target )
resource cpu on pods (as a percentage of request): <unknown> / 80%
Min replicas: 1
Max replicas: 2
Deployment pods: 2 current / 2 desired
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededGetScale the HPA controller was able to get the target's current scale
ScalingActive False FailedGetResourceMetric the HPA was unable to compute the replica count: missing request for cpu
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedGetResourceMetric 3m29s (x4333 over 19h) horizontal-pod-autoscaler missing request for cpu
Si la colonne Message affiche une demande manquante pour [x], vos Deployments ou ReplicaSet ne déclarent probablement pas de demandes de ressources dans sa spécification. Confirmez que tous les conteneurs du pod disposent des demandes déclarées.
Si vous n'omettez ne serait-ce qu'une seule demande, la métrique dans HPA renvoie la réponse <unknown>. Pour plus d'informations, consultez Gestion des ressources pour les conteneurs.
Cet article vous a-t-il été utile ?
Besoin d'aide pour une question technique ou de facturation ?