Pourquoi ne puis-je pas collecter de métriques à partir de conteneurs, de pods ou de nœuds à l'aide de Metrics Server dans Amazon EKS ?

Brève description

Metrics Server n'est pas installé par défaut dans Amazon EKS. Si vous avez récemment créé votre cluster et que vous ne pouvez pas collecter de métriques à 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 des métriques avec Metrics Server, procédez comme indiqué dans les sections suivantes :

• Vérifiez si vous pouvez récupérer des métriques à partir des nœuds et des pods de votre cluster.
• Vérifiez si APIService est disponible et peut traiter les demandes.
• Vérifiez les problèmes courants de GitHub.
• Vérifiez votre Horizontal Pod Autoscaler (HPA) et vos demandes de ressources d'application si les métriques s'affichent en tant que <unknown>.

Remarque : il n'est pas recommandé d'utiliser Metrics Server pour la surveillance à long terme des performances des applications et des clusters. Pour une surveillance à long terme, consultez la page Gestion des ressources pour les pods et les conteneurs du site Web Kubernetes. La communauté Kubernetes gère Metrics Server et signale les problèmes sur sa page GitHub.

Résolution

Consultez les étapes suivantes pour résoudre certains des problèmes les plus courants liés à Metrics Server.

Vérifier si vous pouvez récupérer des métriques à partir des nœuds et des pods de votre cluster

Vérifiez s'il y a des erreurs entre le serveur d'API et Metrics Server. Pour extraire des métriques à partir des nœuds et des pods de votre cluster, exécutez les commandes suivantes :

$ kubectl top nodes

$ kubectl top pods

Si aucune des commandes ne renvoie d'erreur, consultez la section Vérifier si APIService est disponible et peut traiter les demandes.

Si vous recevez un message d'erreur, procédez comme indiqué dans l'une des sections suivantes en fonction de l'erreur 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 un problème avec l'autorisation RBAC. Pour résoudre cette erreur, vérifiez que :

• ServiceAccount est correctement associé au déploiement.
• Les éléments ClusterRole/Role et ClusterRoleBinding/RoleBindings utilisent les autorisations RBAC appropriées pour Metrics Server.

Pour en savoir plus, consultez la page Utilisation de l'autorisation RBAC du site Web Kubernetes.

Si vous accédez à votre cluster via un rôle défini dans le fichier aws-auth ConfigMap, vérifiez que vous avez défini le champ nom d'utilisateur et le mappage.

1. Pour décrire le fichier aws-auth ConfigMap, exécutez la commande suivante :

   $ kubectl describe -n kube-system configmap aws-auth

2. Vérifiez que le champ nom d'utilisateur est défini pour le rôle qui accède 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 détecter un problème lié à la configuration de l'application de service Metrics Server dans votre cluster, exécutez la commande suivante :

$ kubectl describe apiservices v1beta1.metrics.k8s.io

Vous obtiendrez une sortie de ce type :

Name:         v1beta1.metrics.k8s.io
Namespace:
Labels:       app=metrics-server
...
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 réussit les vérifications, le champ Statut est défini sur Vrai.

Si vous définissez le champ Statut sur Vrai et que le problème persiste, consultez la section Vérifier si APIService est disponible et peut traiter les demandes.

Si le champ Statut est défini sur Faux, recherchez le code de motif et le message interprétable par l'utilisateur pour connaître les conditions dans la sortie. Voici un exemple d'APIService défaillant :

...
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, consultez la section Autres motifs d'échec de condition APIServer.

Si le code de motif est FailedDiscoveryCheck, cela signifie que le service Metrics Server est disponible et que les pods sont en cours d'exécution. APIServer Kubernetes renvoie une erreur lorsqu'il tente d'accéder au point de terminaison de Metrics Server.

Si le message de conditions d'APIServer contient Client.Timeout exceeded while awaiting headers, consultez la section Résoudre l'erreur « Client.Timeout exceeded while awaiting headers ».

Si le message de conditions d'APIServer contient connection refused, consultez la section Résoudre l'erreur « connection refused ».

Résoudre l'erreur « Client.Timeout exceeded while awaiting headers »

Ce message d'erreur émis par APIService indique qu'un groupe de sécurité ou une liste de contrôle d'accès réseau (ACL) n'est pas configuré correctement. Cela 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 minimum pour Amazon EKS.

Résoudre l'erreur « connection refused »

Lorsque cette erreur apparaît dans le message APIServer, cela 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 vérifier que les valeurs des ports, de l'image et de la commande sont correctes dans le déploiement metrics-server :

$ kubectl describe deployment metrics-server -n kube-system

Vous obtiendrez une sortie de ce type :

Name:                   metrics-server
Namespace:              kube-system
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 manière dont Metrics Server a été déployé et de l'endroit où les images sont stockées. Si le champ 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 le champ Commande ne contient pas le paramètre --secure-port, le port par défaut est 443.

Autres motifs d'échec de condition APIServer

Si vous recevez l'un des codes suivants pour APIService, prenez les mesures appropriées en fonction du message d'erreur associé : ServiceNotFound, ServiceAccessError, ServicePortError, EndpointsNotFound, EndpointsAccessError ou MissingEndpoints.

1. Pour obtenir des informations sur le service concerné par l'erreur, exécutez la commande suivante :

   $ kubectl get service -n kube-system

   Dans la sortie, vérifiez que le service Kubernetes possède le même nom et le même espace de noms que ceux définis dans APIService.Spec.Service. Vérifiez ensuite 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 -n kube-system

   Dans la sortie, vérifiez que vous disposez d'au moins un point de terminaison pour le service metrics-server :

   NAME             ENDPOINTS         AGE
   metrics-server   10.0.35.231:443   76m

3. Pour vérifier 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 kube-system

   Dans la sortie, vérifiez que le déploiement comporte au moins une réplique :

   Name:                   metrics-server
   Namespace:              kube-system
   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 parvenez toujours pas à collecter des métriques avec Metrics Server, consultez la section Vérifier si APIService est disponible et peut traiter les demandes.

Vérifier si APIService est disponible et peut traiter 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 commencent par un E dans metrics-server :

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 Metrics Server indiquent soit un problème de configuration concernant la commande de déploiement de Metrics Server, soit un bogue lié au conteneur Metrics Server. Si le message d'erreur n'est pas évident ou si vous pensez qu'il s'agit d'un bogue, procédez comme indiqué dans la section Vérifier les problèmes courants de GitHub.

Vérifier les problèmes courants de GitHub

Si vous ne parvenez toujours pas à collecter des métriques à partir de conteneurs, de pods ou de nœuds, vérifiez les problèmes courants de GitHub avec Metrics Server.

Vérifier que vos demandes de ressources HPA et d'application ne contiennent pas de métriques inconnues

1. Pour vérifier la configuration HPA, exécutez la commande suivante :

   $ kubectl get hpa -n namespace 2048-deployment

   Remarque : remplacez espace de noms et 2048-deployment par les valeurs de configuration HPA de votre application. Il se peut que <unknown> s'affiche sous la colonne Cibles de la sortie. Consultez l'exemple suivant :

   NAME              REFERENCE                    TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
   2048-deployment   Deployment/2048-deployment   <unknown>/80%   1         2         2          10s

2. Patientez quelques minutes, puis répétez la commande de l'étape 1.

   Si vous recevez toujours l'erreur <unknown>, exécutez la commande suivante :

   $ kubectl describe hpa -n <namespace> 2048-deployment

   Consultez ensuite la section Événements de la sortie pour en savoir plus :

   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 indique demande manquante pour [x], cela signifie probablement que vos champs Déploiements ou ReplicaSet ne déclarent pas les demandes de ressources dans leurs spécifications. Vérifiez que les demandes sont déclarées dans tous les conteneurs du pod. En cas d'exclusion d'une demande, la métrique dans HPA peut renvoyer la réponse <unknown>.

Pour en savoir plus, consultez la page Gestion des ressources pour les pods et les conteneurs du site Web Kubernetes.