Probleme auf dem Kubernetes API-Server beheben

Auf dieser Seite erfahren Sie, wie Sie Probleme mit dem Kubernetes API-Server (kube-apiserver) für Google Distributed Cloud Virtual for Bare Metal 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 unterschiedliche Weise auftreten. Wenn eines der folgenden Symptome auftritt, schlagen Webhook-Aufrufe möglicherweise fehl:

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 gemeldet:

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

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 dem übereinstimmt, der für die Antwort des API-Servers konfiguriert ist.
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:

Sehen Sie sich die folgenden Vorschläge an, um das 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 ein benutzerdefiniertes Zeitlimit konfigurieren. Die Webhook-Latenz 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 der Webhook die Situation problemlos entfernen und mildern kann, prüfen Sie, ob es möglich ist, den failurePolicy vorübergehend auf Ignore zu setzen oder den betreffenden Webhook zu entfernen.

Ruffehler oder Latenz des API-Servers

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, 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 Kubernetes-Dienst-IP 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 anzuwählen, 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 kann erfolgreich sein, aber bei den Anfragen tritt auf der Clientseite 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. Mit sitzungsspezifischen Kubernetes-Containern kann ein Debugging-Container in die vorhandenen Namespaces eingefügt werden:

Verwenden Sie kubectl, wenn der problematische Client von dort aus eine Anfrage mit hoher Ausführlichkeit ausführt. Beispielsweise ist für eine GET-Anfrage an /healthz normalerweise keine Authentifizierung erforderlich:
```
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 manuell mit curl ausführen. Wenn der aus der vorherigen Ausgabe abgerufene Diensthost 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.

Hinweis: Sie können nicht den Befehl ping oder traceroute für die IP-Adresse verwenden. Eine Kubernetes-Dienst-IP akzeptiert weder ICMP noch Protokolle, die nicht in der in der Dienstressource definierten Liste enthalten sind.

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

Sehen Sie sich die folgenden Lösungsoptionen an, um diese Verbindungsfehler oder Latenzprobleme zu beheben:

Wenn ein Netzwerkfehler innerhalb des Clusters 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 von selbst, nachdem der Pod neu erstellt oder neu geplant wurde.
Wenn der Netzwerkfehler von außerhalb des Clusters verursacht wird, prüfen Sie, ob der Client für den Zugriff auf den Cluster richtig konfiguriert ist, oder generieren Sie die Clientkonfiguration noch einmal. Wenn die Verbindung über einen Proxy oder ein Gateway verläuft, prüfen Sie, ob eine andere Verbindung, die den gleichen Mechanismus durchläuft, funktioniert.
Wenn der API-Server überlastet ist, greifen in der Regel viele Clients gleichzeitig auf den API-Server zu. Durch Drosselung und die Funktion Priorität und Fairness kann ein einzelner Client einen API-Server nicht überlasten. Überprüfen Sie die Arbeitslast auf die folgenden Bereiche:
- Funktioniert auf Pod-Ebene. Pods werden häufiger versehentlich erstellt und vergessen als Ressourcen auf höherer Ebene.
- Passen Sie die Anzahl der Replikate durch fehlerhafte Berechnung an.
- Ein Webhook, der die Anfrage an sich selbst zurückgibt oder die Last erhöht, indem er mehr Anfragen erstellt, als er verarbeitet.

Nächste Schritte

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