Fehlerbehebung beim Kubernetes API-Server

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

Diese Seite richtet sich an IT-Administratoren und ‑Betreiber, die den Lebenszyklus der zugrunde liegenden technischen Infrastruktur verwalten und auf Benachrichtigungen und Seiten reagieren, wenn Service Level Objectives (SLOs) nicht erfüllt werden oder Anwendungen ausfallen. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud-Inhalten verweisen, finden Sie unter Häufig verwendete GKE Enterprise-Nutzerrollen und -Aufgaben.

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

Webhook-Zeitüberschreitungen und fehlgeschlagene Webhook-Aufrufe

Diese Fehler können sich auf unterschiedliche Weise äußern. Wenn eines der folgenden Symptome auftritt, sind Webhook-Aufrufe möglicherweise fehlgeschlagen:

  • Verbindung abgelehnt: Wenn kube-apiserver Zeitüberschreitungsfehler beim Aufrufen des Webhooks meldet, wird in den Logs der folgende Fehler ausgegeben:

    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: Möglicherweise wird in den Logs auch der folgende Fehler angezeigt:

    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 vermuten, dass Webhook-Zeitüberschreitungen oder fehlgeschlagene Webhook-Aufrufe auftreten, können Sie das Problem mit einer der folgenden Methoden prüfen:

  • Prüfen Sie im API-Server-Log, ob ein Netzwerkproblem vorliegt.

    • Prüfen Sie das Log auf netzwerkbezogene Fehler wie TLS handshake error.
    • Prüfen Sie, ob die IP-Adresse/der Port der Konfiguration des API-Servers in Bezug auf Reaktionen entspricht.

  • So ü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:

Versuchen Sie, dieses Problem mit den folgenden Vorschlägen 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 die Ausführung des Webhooks mehr Zeit in Anspruch nimmt, können Sie einen benutzerdefinierten Zeitlimitwert konfigurieren. Die Webhook-Latenz erhöht die API-Anfragelatenz und sollte daher so schnell wie möglich ausgewertet werden.

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

API-Server-Anruffehler oder Latenz

Dieser Fehler kann auf verschiedene Arten deutlich werden:

  • Fehler bei der externen Namensauflösung: Ein externer Client kann Fehler zurückgeben, die lookup in der Meldung enthalten, z. B.:

    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, sodass keine Auflösung erforderlich ist.

  • Netzwerkfehler: Der Client gibt möglicherweise einen generischen Netzwerkfehler aus, wenn er versucht, den API-Server anzurufen. Beispiele:

    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

  • Hohe Latenz bei der Verbindung zum API-Server: Die Verbindung zum API-Server ist möglicherweise erfolgreich, aber bei den Anfragen treten Zeitüberschreitungen auf der Clientseite auf. In diesem Fall gibt der Client in der Regel Fehlermeldungen mit context deadline exceeded aus.

Wenn die Verbindung zum API-Server vollständig fehlschlägt, versuchen Sie, sie in derselben Umgebung herzustellen, in der der Client den Fehler meldet. Mit sitzungsspezifischen Kubernetes-Containern können Sie einen Debug-Container in die vorhandenen Namespaces einschleusen. Gehen Sie dazu so vor:

  1. Führen Sie an dem Ort, an dem der problematische Client ausgeführt wird, mit kubectl eine Anfrage mit hoher Ausführlichkeit aus. Für eine GET-Anfrage an /healthz ist beispielsweise in der Regel keine Authentifizierung erforderlich:

    kubectl get -v999 --raw /healthz

  2. Wenn die Anfrage fehlschlägt oder kubectl nicht verfügbar ist, können Sie die URL aus der Ausgabe abrufen und die Anfrage manuell mit curl ausführen. Wenn der Diensthost aus der vorherigen Ausgabe beispielsweise https://192.0.2.1:36917/ war, können Sie so eine ähnliche Anfrage 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 in der Regel die Ursache für eine fehlgeschlagene Verbindung an.

    Wenn die Verbindung zwar erfolgreich, aber langsam ist oder mit einer Zeitüberschreitung auftritt, ist der API-Server überlastet. Sehen Sie sich zur Bestätigung in der Console API Server Request Rate und die Latenzmesswerte der Anfrage in Cloud Kubernetes > Anthos > Cluster > K8s Control Plane an.

Um diese Verbindungsfehler oder Latenzprobleme zu beheben, können Sie die folgenden Optionen ausprobieren:

  • 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 wird nach dem Neuerstellen oder Neuplanen des Pods behoben.

  • 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 erfolgt, prüfen Sie, ob eine andere Verbindung, die denselben Mechanismus verwendet, funktioniert.

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

    • Funktioniert auf Pod-Ebene. Pods werden häufiger als Ressourcen auf höherer Ebene versehentlich erstellt und vergessen.
    • Passen Sie die Anzahl der Replikate aufgrund einer fehlerhaften Berechnung an.
    • Ein Webhook, der die Anfrage an sich selbst zurücksendet oder die Last verstärkt, indem mehr Anfragen erstellt werden, als er verarbeiten kann.

Nächste Schritte

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