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.

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 auf verschiedene Arten angezeigt werden. Wenn eines der folgenden Symptome auftritt, können Webhook-Aufrufe fehlschlagen:

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

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 wird möglicherweise 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 davon ausgehen, dass Webhook-Zeitüberschreitungen oder fehlgeschlagene Webhook-Aufrufe auftreten, verwenden Sie eine der folgenden Methoden, um das Problem zu bestätigen:

Sehen Sie im API-Serverprotokoll nach, ob ein Netzwerkproblem vorliegt.
- Prüfen Sie das Log auf netzwerkbezogene Fehler wie TLS handshake error.
- Prüfen Sie, ob der IP-/Port mit dem übereinstimmt, wie der API-Server für Antworten konfiguriert ist.
Überwachen Sie die Webhook-Latenz mit den folgenden Schritten:
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 der Webhook mehr Zeit benötigt, können Sie einen benutzerdefinierten Zeitlimitwert konfigurieren. Die Latenz der Webhooks erhöht die Latenz der API-Anfrage zusätzlich. Daher sollte sie 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 auftreten:

Fehler bei der externen Namensauflösung: Ein externer Client gibt möglicherweise Fehler zurück, die lookup in der Nachricht enthalten. Dazu gehören:
```
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 zu wählen, wie in den folgenden Beispielen:
```
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 beim Herstellen einer Verbindung zum API-Server: Die Verbindung zum API-Server ist möglicherweise erfolgreich, aber die Anfragen verursachen eine Zeitüberschreitung auf Clientseite. 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, 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:

Verwenden Sie von dort aus, wo der problematische Client ausgeführt wird, kubectl, um eine Anfrage mit hoher Ausführlichkeit auszuführen. Beispielsweise erfordert eine GET-Anfrage an /healthz normalerweise keine Authentifizierung:
```
kubectl get -v999 --raw /healthz
```
Wenn die Anfrage fehlschlägt oder kubectl nicht verfügbar ist, können Sie die URL aus der Ausgabe abrufen und die Anfrage mit curl manuell ausführen. Wenn der aus der vorherigen Ausgabe abgerufene Diensthost 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 zeigt in der Regel die Ursache einer fehlgeschlagenen Verbindung an.

Hinweis: Sie können die Befehle ping oder traceroute nicht für die IP-Adresse verwenden. Eine Kubernetes-Dienst-IP akzeptiert weder ICMP noch Protokolle außerhalb der in der Dienstressource definierten Liste.

Wenn die Verbindung erfolgreich, aber langsam ist oder das Zeitlimit überschreitet, weist dies auf einen überlasteten API-Server hin. Zur Bestätigung sehen Sie sich in der Console 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 innerhalb des Clusters ein Netzwerkfehler auftritt, liegt möglicherweise ein Problem mit dem Plug-in Container Network Interface (CNI) vor. Dieses Problem ist in der Regel vorübergehend und löst sich nach einer Pod-Neuerstellung oder -Neuplanung selbst.
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 den gleichen Mechanismus nutzt, 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. Prüfen Sie die Arbeitslast für die folgenden Bereiche:
- Funktioniert auf Pod-Ebene. Es ist häufiger, dass Pods versehentlich erstellt und vergessen werden als übergeordnete Ressourcen.
- Passen Sie die Anzahl der Replikate durch fehlerhafte Berechnung an.
- Ein Webhook, der die Anfrage in einer Schleife an sich selbst zurückgibt 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.