Warum kann ich mit Metrics Server in Amazon EKS keine Metriken aus Containern, Pods oder Knoten sammeln?

Kurzbeschreibung

In Amazon EKS ist Metrics Server nicht standardmäßig installiert. Wenn Sie Ihren Cluster gerade erstellt haben und mit Metrics Server keine Metriken sammeln können, stellen Sie sicher, dass Sie die Metrics Server-Anwendung in Ihrem Cluster bereitgestellt haben.

Wenn Sie mit Metrics Server immer noch keine Metriken erfassen können, führen Sie die Schritte in den folgenden Abschnitten aus:

• Überprüfen Sie, ob Sie Metriken von den Knoten und Pods Ihres Clusters abrufen können.
• Überprüfen Sie, ob der APIService verfügbar ist und Anfragen bearbeiten kann.
• Auf GitHub finden Sie häufig auftretende Probleme.
• Überprüfen Sie in Ihrem Horizontal Pod Autoscaler (HPA) und Ihren Anwendungsressourcenanfragen, ob die Metriken angezeigt werden als <unknown>.

Hinweis: Metrics Server ist nicht für die langfristige Überwachung der Anwendungs- und Clusterleistung vorgesehen. Informationen zur langfristigen Überwachung finden Sie unter Ressourcenmanagement für Pods und Container auf der Kubernetes-Website. Die Kubernetes-Community verwaltet Metrics Server und meldet Probleme auf ihrer GitHub-Seite.

Lösung

Lesen Sie die folgenden Schritte, um einige der häufigsten Probleme mit Metrics Server zu beheben.

Überprüfen, ob Metriken von den Knoten und Pods Ihres Clusters abgerufen werden können

Suchen Sie nach Fehlern zwischen dem API-Server und dem Metrics Server. Führen Sie die folgenden Befehle aus, um Metriken aus den Knoten und Pods Ihres Clusters abzurufen:

$ kubectl top nodes

$ kubectl top pods

Wenn Sie bei keinem der Befehle eine Fehlermeldung erhalten, führen Sie die Schritte im Abschnitt Überprüfen, ob der APIService verfügbar ist und Anfragen bearbeiten kann aus.

Wenn Sie eine Fehlermeldung erhalten, führen Sie die Schritte in einem der folgenden Abschnitte auf der Grundlage des Fehlers aus, den Sie erhalten haben:

• Fehler vom Server (Forbidden)
• Fehler vom Server (ServiceUnavailable)
• Client.Timeout exceeded while awaiting headers
• Verbindung verweigert

Fehler vom Server (Forbidden)

Diese Fehlermeldung weist darauf hin, dass Sie ein Problem mit der RBAC-Autorisierung haben. Überprüfen Sie die folgenden Punkte, um diesen Fehler zu beheben:

• Der ServiceAccount ist korrekt an die Bereitstellung angehängt.
• Die ClusterRole/Role und ClusterRoleBinding/RoleBindings verwenden die richtigen RBAC-Berechtigungen für Metrics Server.

Weitere Informationen finden Sie unter Verwenden der RBAC-Autorisierung auf der Kubernetes-Website.

Wenn Sie über eine in der aws-auth ConfigMap definierte Rolle auf Ihren Cluster zugreifen, bestätigen Sie, dass Sie das Feld username und die Zuordnung festgelegt haben.

1. Führen Sie den folgenden Befehl aus, um die aws-auth ConfigMap zu beschreiben:

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

2. Vergewissern Sie sich, dass das Feld username für die Rolle eingerichtet ist, die auf den Cluster zugreift. Siehe folgendes Beispiel:

   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.

Fehler vom Server (ServiceUnavailable)

Führen Sie den folgenden Befehl aus, um nach Problemen mit der Konfiguration der Metrics Server-Dienstanwendung in Ihrem Cluster zu suchen:

$ kubectl describe apiservices v1beta1.metrics.k8s.io

Die Ausgabe sieht dem folgenden Beispiel ähnlich:

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>

Wenn der Metrics Server-Dienst verfügbar ist und die Überprüfungen bestanden hat, wird Status auf True gesetzt.

Wenn Sie Status auf True setzen und das Problem weiterhin besteht, finden Sie weitere Informationen im Abschnitt Überprüfen, ob der APIService verfügbar ist und Anfragen bearbeiten kann.

Wenn Status auf False gesetzt ist, suchen Sie in der Ausgabe nach dem zugehörigen Ursachen-Code und der lesbaren Meldung für Bedingungen. Sehen Sie sich das folgende Beispiel für einen fehlgeschlagenen APIService an:

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

Wenn die Ursache nicht FailedDiscoveryCheck ist, führen Sie die Schritte im Abschnitt Weitere Ursachen für APIServer-Bedingungsfehler durch.

Wenn der Ursachencode FailedDiscoveryCheck lautet, ist der Metrics Server-Dienst verfügbar und die Pods werden ausgeführt. Der Kubernetes-APIServer gibt einen Fehler zurück, wenn er versucht, den Metrics Server-Endpunkt zu erreichen.

Wenn die APIServer-Bedingungsmeldung Client.Timeout beim Warten auf Header überschritten enthält, führen Sie die Schritte im Abschnitt Fehler „Client.Timeout exceeded while awaiting headers“ beheben aus.

Wenn die APIServer-Bedingungsmeldung connection refused enthält, führen Sie die Schritte im Abschnitt Fehler „connection refused“ beheben durch.

Fehler „Client.Timeout exceeded while awaiting headers“ beheben

Diese Fehlermeldung im APIService weist darauf hin, dass eine Sicherheitsgruppe oder eine Zugriffssteuerungsliste (ACL) nicht richtig konfiguriert ist. Dadurch wird der Zugriff auf die metrics-server-Pods verhindert. Siehe folgendes Beispiel:

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)

Um diesen Fehler zu beheben, stellen Sie sicher, dass Ihre Sicherheitsgruppen die Mindestanforderungen an den Datenverkehr für Amazon EKS erfüllen.

Fehler „connection refused“ beheben

Dieser Fehler in der APIServer-Meldung weist darauf hin, dass der Container auf dem falschen Port lauscht. Siehe folgendes Beispiel:

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

Um diesen Fehler zu beheben, führen Sie den folgenden Befehl aus, um zu überprüfen, ob die Werte für Ports, Image und Command in der metrics-server-Bereitstellung korrekt sind:

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

Die Ausgabe sieht dem folgenden Beispiel ähnlich:

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

**Hinweis:**Die Werte für Command und Image können variieren, je nachdem, wie Metrics Server bereitgestellt wurde und wo die Bilder gespeichert sind. Wenn Command den Parameter --secure-port enthält, muss der vom Pod verfügbar gemachte Port (443/TCP, im vorherigen Beispiel) mit diesem Parameter übereinstimmen. Wenn Command den Parameter --secure-port nicht enthält, ist der Port standardmäßig 443.

Andere Gründe für einen Ausfall von APIServer

Wenn Sie einen der folgenden Codes für den APIService erhalten, ergreifen Sie Maßnahmen entsprechend der zugehörigen Fehlermeldung: ServiceNotFound, ServiceAccessError, ServicePortError, EndpointsNotFound, EndpointsAccessError oder MissingEndpoints.

1. Führen Sie den folgenden Befehl aus, um Informationen über den Dienst mit dem Fehler zu erhalten:

   $ kubectl get service -n kube-system

   Vergewissern Sie sich in der Ausgabe, dass der Kubernetes-Dienst denselben Namen und Namespace hat wie in APIService.Spec.Service definiert. Vergewissern Sie sich dann, dass der Port auf 443/TCP eingestellt ist. Siehe folgendes Beispiel:

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

2. Führen Sie den folgenden Befehl aus, um Endpunkte aufzulisten:

   $ kubectl get endpoints metrics-server -n kube-system

   Vergewissern Sie sich in der Ausgabe, dass Sie mindestens einen Endpunkt für den metrics-server-Dienst haben:

   NAME             ENDPOINTS         AGE
   metrics-server   10.0.35.231:443   76m

3. Führen Sie den folgenden Befehl aus, um zu überprüfen, ob die Bereitstellung vorhanden ist und ob die Bezeichnungen mit denen des metrics-server-Dienstes übereinstimmen:

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

   Vergewissern Sie sich in der Ausgabe, dass die Bereitstellung über mindestens ein Replikat verfügt:

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

Wenn Sie mit Metrics Server immer noch keine Metriken erfassen können, führen Sie die Schritte im Abschnitt Überprüfen, ob der APIService verfügbar ist und Anfragen bearbeiten kann aus.

Überprüfen, ob der APIService verfügbar ist und Anfragen bearbeiten kann

Führen Sie den folgenden Befehl aus, um Protokolle aus Ihren Metrics Server-Pods zu extrahieren:

$ kubectl logs -n <namespace> -l app=metrics-server

Zum Beispiel beginnen Fehlerprotokolle auf dem metrics-server mit einem 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"

Metrics Server-Fehlerprotokolle weisen entweder auf ein Konfigurationsproblem im Metrics Server Deployment Command oder auf einen Fehler im Metrics Server-Container hin. Wenn die Fehlermeldung nicht offensichtlich ist oder Sie vermuten, dass es sich um eine Falschmeldung handelt, führen Sie die Schritte im Abschnitt GitHub auf häufig auftretende Probleme überprüfen.

GitHub auf häufig auftretende Probleme überprüfen

Wenn Sie immer noch keine Metriken aus Containern, Pods oder Knoten sammeln können, dann überprüfen Sie GitHub auf häufig auftretende Probleme mit Metrics Server.

Überprüfen Sie Ihre HPA- und Anwendungsressourcenanfragen auf unbekannte Metriken

1. Führen Sie den folgenden Befehl aus, um die HPA-Konfiguration zu überprüfen:

   $ kubectl get hpa -n namespace 2048-deployment

   Hinweis: Ersetzen Sie namespace und 2048-deployment durch die HPA-Konfigurationswerte für Ihre Anwendung. Sie könnten sehen <unknown> in der Spalte Ziele der Ausgabe. Siehe folgendes Beispiel:

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

2. Warten Sie einige Minuten und wiederholen Sie dann den Befehl aus Schritt 1.

   Wenn Sie immer noch den Fehler erhalten <unknown>, führen Sie den folgenden Befehl aus:

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

   Weitere Informationen finden Sie dann im Abschnitt Events der Ausgabe:

   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

   Wenn in der Spalte Message eine fehlende Anfrage für [x] angezeigt wird, deklarieren Ihre Bereitstellungen oder ReplicaSet wahrscheinlich keine Ressourcenanforderungen in ihrer Spezifikation. Vergewissern Sie sich, dass für alle Container im Pod die Anfragen deklariert sind. Das Auslassen einer Anfrage kann dazu führen, dass die Metrik in HPA die Antwort <unknown> zurückgibt.

Weitere Informationen finden Sie unter Ressourcenmanagement für Pods und Container auf der Kubernetes-Website.