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

Résolution

Amazon EKS n'installe pas automatiquement Metrics Server. Si vous avez récemment créé le cluster et que vous ne pouvez pas utiliser Metrics Server pour collecter des métriques, vérifiez que vous avez déployé l'application Metrics Server sur le cluster.

Si vous ne parvenez toujours pas à collecter des métriques avec Metrics Server, procédez comme indiqué dans les sections suivantes.

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. Pour plus d'informations, consultez la page Problèmes sur la page GitHub de Metrics Server.

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

Pour vérifier si vous pouvez récupérer des métriques à partir des nœuds et des pods du cluster, exécutez les commandes suivantes :

kubectl top nodes
kubectl top pods

Remarque : 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 une erreur à partir de la commande précédente, suivez les étapes décrites dans l'une des sections suivantes en fonction de l'erreur reçue.

Message d’erreur « Error from server (Forbidden) »

Si vous rencontrez un problème avec l'autorisation du contrôle d'accès basé sur les rôles (RBAC), vous recevez un message d'erreur « Error from server (Forbidden) ».

Pour résoudre cette erreur, procédez comme suit :

• Vérifiez que le ServiceAccount est correctement associé au déploiement.
• Vérifiez que 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 de 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 de nom d'utilisateur et le mappage.

Procédez comme suit :

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

   kubectl describe -n kube-system configmap aws-auth

2. Examinez le résultat de la commande précédente pour confirmer que le champ de nom d'utilisateur est défini pour le rôle qui accède au cluster.
   Exemple de sortie :

   Name:         aws-auth
   Namespace:    kube-system
   Labels:       
   Annotations:  <none>
   
   Data
   ===
   mapRoles:
   ----
   ...
   - groups:
     - system:masters
     rolearn: arn:aws:iam::123456789123:role/kubernetes-devops
     username: devops:`SessionName`

   Assurez-vous que le nom d'utilisateur est spécifié dans la sortie.

Message d'erreur « Error from server (ServiceUnavailable) »

Si Metrics Server n'est pas correctement configuré, le message d'erreur « Error from server (ServiceUnavailable) » s'affiche.

Pour détecter un problème lié à la configuration de l'application de service Metrics Server dans le cluster, exécutez la commande suivante :

kubectl describe apiservices v1beta1.metrics.k8s.io

Exemple de sortie :

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.

Remarque : 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.

Exemple d'échec d’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

Remarque : si le motif n’est pas FailedDiscoveryCheck, consultez la section Autres motifs d'échec de condition APIServer. 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 »

Si vous n'avez pas configuré correctement un groupe de sécurité ou une liste de contrôle d'accès au réseau (ACL réseau), le message d'erreur « Client.Timeout exceeded will waiting headers » s'affiche sur l'APIService. Dans ce cas, vous ne pouvez pas accéder aux pods metrics-server.

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 »

Si un conteneur écoute sur le mauvais port, le message d'erreur « Connection refused » s'affiche.

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

Exemple de sortie :

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 varient en fonction de la manière dont vous déployez Metrics Server et de l'endroit où vous stockez les images. Si la commande contient le paramètre --secure-port, le port exposé par le pod doit correspondre à ce paramètre. Si le champ Commande n’inclut 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.

Pour résoudre les erreurs, procédez comme suit :

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.
   Exemple de sortie :

   NAME                             TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
   metrics-server                   ClusterIP   172.20.172.133   <none>        443/TCP    65m

2. Exécutez la commande suivante pour répertorier tous les points de terminaison :

   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.
   Exemple de sortie :

   NAME             ENDPOINTS         AGE
   metrics-server   10.0.35.231:443   76m

3. Exécutez la commande suivante pour vérifier que le déploiement est présent et que les étiquettes correspondent à celles du service metrics-server :

   kubectl describe deploy metrics-server -n kube-system

   Dans la sortie, vérifiez que le déploiement inclut au moins un réplica.
   Exemple de sortie :

   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

Exécutez la commande suivante pour extraire les journaux des pods Metrics Server :

kubectl logs -n namespace -l app=metrics-server

Remarque : remplacez namespace par votre espace de noms.
Exemples de journaux d'erreurs :

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"

Remarque : les journaux d'erreurs de Metrics Server indiquent si vous avez un problème de configuration concernant la commande de déploiement de Metrics Server ou 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. Pour plus d'informations, consultez la page Problèmes sur la page GitHub de Metrics Server.

Pour vérifier la présence de métriques inconnues dans HorizontalPodAutoscaler (HPA) et les demandes de ressources d'application, procédez comme suit :

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 de votre application.
   Il se peut que <unknown> s'affiche sous la colonne Cibles de la sortie.
   Exemple de sortie :

   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

   Remarque : remplacez namespace par votre espace de noms.
   Puis, consultez la section Événements de la sortie pour en savoir plus.
   Exemple de sortie :

   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

   Remarque : si la colonne Message indique demande manquante pour [x], cela signifie probablement que les 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. Si vous omettez une demande, la métrique dans HPA renvoie la réponse <unknown>.
   Pour plus d'informations, consultez la page Gestion des ressources pour les pods et les conteneurs, Déploiements et ReplicaSet sur le site Web de Kubernetes.