Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
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:
Rufen Sie in der Console die Seite „Cloud Monitoring“ auf.
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:
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:
kubectlget-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 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.pemhttps://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.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2024-11-28 (UTC)."],[],[],null,["This page shows you how to resolve issues with the Kubernetes API server\n(`kube-apiserver`) for Google Distributed Cloud.\n\nThis page is for IT administrators and Operators who manage the\nlifecycle of the underlying tech infrastructure, and respond to alerts and pages\nwhen service level objectives (SLOs) aren't met or applications fail. To learn\nmore about common roles and example tasks that we reference in Google Cloud\ncontent, see\n[Common GKE user roles and tasks](/kubernetes-engine/enterprise/docs/concepts/roles-tasks).\n\nWebhook timeouts and failed webhook calls\n\nThese errors might be seen in a few different ways. If you experience any of the\nfollowing symptoms, it's possible that webhook calls are failing:\n\n- **Connection refused:** If `kube-apiserver` reports timeout errors for\n calling the webhook, the following error is reported in the logs:\n\n failed calling webhook \"server.system.private.gdc.goog\":\n failed to call webhook: Post \"https://root-admin-webhook.gpc-system.svc:443/mutate-system-private-gdc-goog-v1alpha1-server?timeout=10s\":\n dial tcp 10.202.1.18:443: connect: connection refused\n\n- **Context deadline exceeded:** You might also see the following error reported\n in the logs:\n\n failed calling webhook \"namespaces.hnc.x-k8s.io\": failed to call webhook: Post\n \"https://hnc-webhook-service.hnc-system.svc:443/validate-v1-namespace?timeout=10s\\\":\n context deadline exceeded\"\n\nIf you think that you are experiencing webhook timeouts or failed webhook calls,\nuse one of the following methods to confirm the issue:\n\n- Check the API server log to see if there is network issue.\n\n - Check the log for network-related errors like `TLS handshake error`.\n - Check if the IP/Port matches what the API server is configured to respond on.\n- Monitor webhook latency with the following steps:\n\n 1. In the console, go to the Cloud Monitoring page.\n\n [Go to the Cloud Monitoring page](https://console.cloud.google.com/monitoring/)\n 2. Select **Metrics explorer**.\n\n 3. Select the `apiserver_admission_webhook_admission_duration_seconds` metric.\n\nTo resolve this issue, review the following suggestions:\n\n- Additional firewall rules might be required for the webhook. For more\n information, see how to\n [add firewall rules for specific use cases](/kubernetes-engine/docs/how-to/private-clusters#add_firewall_rules).\n\n- If the webhook requires more time to complete, you can\n [configure a custom timeout value](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#timeouts).\n The webhooks latency adds to API request latency, so should be evaluated as\n quickly as possible.\n\n- If the webhook error blocks cluster availability or the webhook is harmless\n to remove and mitigates the situation, check if it's possible to temporarily\n set the `failurePolicy` to `Ignore` or remove the offending webhook.\n\nAPI server dial failure or latency\n\nThis error might be seen in a few different ways:\n\n- **External name resolution errors:** An external client might return errors\n that contain `lookup` in the message, such as:\n\n dial tcp: lookup kubernetes.example.com on 127.0.0.1:53: no such host\n\n This error doesn't apply to a client running within the cluster. The\n Kubernetes Service IP is injected, so no resolution is required.\n- **Network errors:** The client might print a generic network error when trying\n to dial the API server, like the following examples:\n\n dial tcp 10.96.0.1:443: connect: no route to host\n dial tcp 10.96.0.1:443: connect: connection refused\n dial tcp 10.96.0.1:443: connect: i/o timeout\n\n- **High latency connecting to API server:** The connection to API server might\n be successful, but the requests timeout on the client side. In this scenario,\n the client usually prints error messages containing `context deadline\n exceeded`.\n\nIf the connection to the API server fails completely, try the connection within\nthe same environment where the client reports the error.\n[Kubernetes ephemeral containers](https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/)\ncan be used to inject a debugging container to the existing namespaces as\nfollows:\n\n1. From where the problematic client runs, use `kubectl` to perform a request\n with high verbosity. For example, a `GET` request to `/healthz` usually\n requires no authentication:\n\n kubectl get -v999 --raw /healthz\n\n2. If the request fails or `kubectl` is unavailable, you can obtain the URL from\n the output and manually perform the request with `curl`. For example, if the\n service host obtained from the previous output was `https://192.0.2.1:36917/`,\n you can send a similar request as follows:\n\n # Replace \"--ca-cert /path/to/ca.pem\" to \"--insecure\" if you are accessing\n # a local cluster and you trust the connection cannot be tampered.\n # The output is always \"ok\" and thus contains no sensentive information.\n\n curl -v --cacert /path/to/ca.pem https://192.0.2.1:36917/healthz\n\n The output from this command usually indicates the root cause of a failed\n connection.\n | **Note:** You can't use the `ping` or `traceroute` commands to the IP address. A Kubernetes Service IP doesn't accept ICMP or protocols outside the list defined in the Service resource.\n\n If the connection is successful but is slow or times out, it indicates an\n overloaded API server. To confirm, in the console look at `API\n Server Request Rate` and request latency metrics in `Cloud Kubernetes \u003e Anthos \u003e\n Cluster \u003e K8s Control Plane`.\n\nTo resolve these connection failures or latency problems, review the following\nremediation options:\n\n- If a network error occurs within the cluster, there might be problem with the\n Container Network Interface (CNI) plugin. This problem is usually transient\n and resolves itself after a Pod recreation or reschedule.\n\n- If the network error is from outside the cluster, check if the client is\n properly configured to access the cluster, or generate the client\n configuration again. If the connection goes through a proxy or gateway, check\n if another connection that goes through the same mechanism works.\n\n- If the API server is overloaded, it usually means that many clients access the\n API server at the same time. A single client can't overload an API server due\n to throttling and the\n [Priority and Fairness](https://kubernetes.io/docs/concepts/cluster-administration/flow-control/)\n feature. Review the workload for the following areas:\n\n - Works at Pod level. It's more common to mistakenly create and forget Pods than higher level resources.\n - Adjust the number of replicas through erroneous calculation.\n - A webhook that loops back the request to itself or amplifies the load by creating more requests than it handles.\n\nWhat's next\n\nIf you need additional assistance, reach out to\n\n[Cloud Customer Care](/support-hub).\n\nYou can also see\n[Getting support](/kubernetes-engine/distributed-cloud/vmware/docs/getting-support) for more information about support resources, including the following:\n\n- [Requirements](/kubernetes-engine/distributed-cloud/vmware/docs/getting-support#support_requirements) for opening a support case.\n- [Tools](/kubernetes-engine/distributed-cloud/vmware/docs/getting-support#support_tools) to help you troubleshoot, such as logs and metrics.\n- Supported [components](/kubernetes-engine/distributed-cloud/vmware/docs/getting-support#whats_supported), [versions](/kubernetes-engine/distributed-cloud/vmware/docs/getting-support#version_support_policy), and [features](/kubernetes-engine/distributed-cloud/vmware/docs/getting-support#supported_features) of Google Distributed Cloud for VMware (software only)."]]
