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 ?

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.

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.