Fehler beim Kubernetes API-Server beheben

Auf dieser Seite erfahren Sie, wie Sie Probleme mit dem Kubernetes API-Server (kube-apiserver) für Google Distributed Cloud beheben.

Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.

Webhook-Zeitlimits und fehlgeschlagene Webhook-Aufrufe

Diese Fehler können auf unterschiedliche Weise auftreten. Wenn eines der folgenden Symptome auftritt, können Webhook-Aufrufe fehlschlagen:

  • Verbindung abgelehnt: Wenn kube-apiserver Zeitüberschreitungsfehler für den Aufruf des Webhooks meldet, wird der folgende Fehler in den Logs angezeigt:

    failed calling webhook "server.system.private.gdc.goog":
failed to call webhook: Post "https://root-admin-webhook.gpc-system.svc:443/mutate-system-private-gdc-goog-v1alpha1-server?timeout=10s":
dial tcp 10.202.1.18:443: connect: connection refused

  • Kontextfrist überschritten:In den Logs kann auch der folgende Fehler angezeigt werden:

    failed calling webhook "namespaces.hnc.x-k8s.io": failed to call webhook: Post
"https://hnc-webhook-service.hnc-system.svc:443/validate-v1-namespace?timeout=10s\":
context deadline exceeded"

Wenn Sie der Meinung sind, dass Webhook-Zeitüberschreitungen oder fehlgeschlagene Webhook-Aufrufe auftreten, können Sie das Problem mit einer der folgenden Methoden bestätigen:

  • Sehen Sie im API-Serverprotokoll nach, ob ein Netzwerkproblem vorliegt.

    • Prüfen Sie das Protokoll auf netzwerkbezogene Fehler wie TLS handshake error.
    • Prüfen Sie, ob die IP-Adresse/der Port mit der Konfiguration des API-Servers übereinstimmt, auf die er antwortet.

  • Mit den folgenden Schritten überwachen Sie die Webhook-Latenz:

    1. Rufen Sie in der Console die Seite "Cloud Monitoring" auf.

      Zur Seite "Cloud Monitoring"

    2. Wählen Sie Metrics Explorer aus.

    3. Wählen Sie den Messwert apiserver_admission_webhook_admission_duration_seconds aus:

Sehen Sie sich die folgenden Vorschläge an, um dieses Problem zu beheben:

  • Für den Webhook sind möglicherweise zusätzliche Firewallregeln erforderlich. Weitere Informationen finden Sie unter Firewallregeln für bestimmte Anwendungsfälle hinzufügen.

  • Wenn der Webhook mehr Zeit benötigt, können Sie einen benutzerdefinierten Wert für die Zeitüberschreitung konfigurieren. Die Latenz von Webhooks erhöht die Latenz von API-Anfragen und sollte daher so schnell wie möglich ausgewertet werden.

  • Wenn der Webhook-Fehler die Clusterverfügbarkeit blockiert oder sich der Webhook nicht entfernen lässt und so die Situation verringert, prüfen Sie, ob es möglich ist, den failurePolicy vorübergehend auf Ignore zu setzen oder den problematischen Webhook zu entfernen.

Einwahlfehler oder Latenz des API-Servers

Dieser Fehler kann auf unterschiedliche Weise auftreten:

  • Fehler bei der Auflösung externer Namen: Ein externer Client kann z. B. Fehler zurückgeben, die lookup in der Nachricht enthalten. Beispiele:

    dial tcp: lookup kubernetes.example.com on 127.0.0.1:53: no such host

    Dieser Fehler gilt nicht für einen Client, der im Cluster ausgeführt wird. Die IP-Adresse des Kubernetes-Dienstes wird eingefügt, daher ist keine Auflösung erforderlich.

  • Netzwerkfehler:Der Client gibt möglicherweise einen generischen Netzwerkfehler aus, wenn er versucht, den API-Server anzurufen, wie in den folgenden Beispielen gezeigt:

    dial tcp 10.96.0.1:443: connect: no route to host
dial tcp 10.96.0.1:443: connect: connection refused
dial tcp 10.96.0.1:443: connect: i/o timeout

  • Verbindung zum API-Server mit hoher Latenz:Die Verbindung zum API-Server ist möglicherweise erfolgreich, aber auf der Clientseite tritt eine Zeitüberschreitung auf. In diesem Szenario gibt der Client normalerweise Fehlermeldungen aus, die context deadline exceeded enthalten.

Wenn die Verbindung zum API-Server vollständig fehlschlägt, versuchen Sie, die Verbindung in derselben Umgebung herzustellen, in der der Client den Fehler meldet. Sitzungsspezifische Kubernetes-Container können so verwendet werden, um einen Debugging-Container in die vorhandenen Namespaces einzufügen:

  1. Verwenden Sie kubectl, um von dort aus, wo der problematische Client ausgeführt wird, eine Anfrage mit hoher Ausführlichkeit auszuführen. Eine GET-Anfrage an /healthz erfordert normalerweise keine Authentifizierung:

    kubectl get -v999 --raw /healthz

  2. Wenn die Anfrage fehlschlägt oder kubectl nicht verfügbar ist, können Sie die URL der Ausgabe entnehmen und die Anfrage mit curl manuell ausführen. Wenn der Diensthost aus der vorherigen Ausgabe beispielsweise https://192.0.2.1:36917/ war, können Sie eine ähnliche Anfrage so senden:

    # Replace "--ca-cert /path/to/ca.pem" to "--insecure" if you are accessing
# a local cluster and you trust the connection cannot be tampered.
# The output is always "ok" and thus contains no sensentive information.

curl -v --cacert /path/to/ca.pem https://192.0.2.1:36917/healthz

    Die Ausgabe dieses Befehls gibt normalerweise die Ursache einer fehlgeschlagenen Verbindung an.

    Wenn die Verbindung erfolgreich, aber langsam ist oder eine Zeitüberschreitung auftritt, weist dies auf einen überlasteten API-Server hin. Sehen Sie sich zur Bestätigung in der Konsole API Server Request Rate an und fordern Sie Latenzmesswerte in Cloud Kubernetes > Anthos > Cluster > K8s Control Plane an.

Prüfen Sie die folgenden Optionen, um diese Verbindungsfehler oder Latenzprobleme zu beheben:

  • Wenn im Cluster ein Netzwerkfehler auftritt, liegt möglicherweise ein Problem mit dem CNI-Plug-in (Container Network Interface) vor. Dieses Problem ist in der Regel vorübergehend und löst sich nach einer Pod-Neuerstellung oder -Neuplanung.

  • Wenn der Netzwerkfehler von außerhalb des Clusters stammt, prüfen Sie, ob der Client richtig für den Zugriff auf den Cluster konfiguriert ist, oder generieren Sie die Clientkonfiguration noch einmal. Wenn die Verbindung über einen Proxy oder ein Gateway läuft, prüfen Sie, ob eine andere Verbindung, die denselben Mechanismus verwendet, funktioniert.

  • Wenn der API-Server überlastet ist, bedeutet dies in der Regel, dass viele Clients gleichzeitig auf den API-Server zugreifen. Ein einzelner Client kann einen API-Server aufgrund der Drosselung und der Funktion Priorität und Fairness nicht überlasten. Überprüfen Sie die Arbeitslast auf die folgenden Bereiche:

    • Funktioniert auf Pod-Ebene. Es kommt häufiger vor, Pods versehentlich zu erstellen und zu vergessen als Ressourcen einer höheren Ebene.
    • Anzahl der Replikate durch fehlerhafte Berechnung anpassen.
    • Ein Webhook, der die Anfrage an sich selbst zurücksendet oder die Last erhöht, indem mehr Anfragen erstellt werden, als er verarbeitet.

Nächste Schritte

Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.