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 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:
Rufen Sie in der Console die Seite Cloud Monitoring auf.
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:
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 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.pemhttps://192.0.2.1:36917/healthz
Die Ausgabe dieses Befehls zeigt in der Regel die Ursache einer fehlgeschlagenen Verbindung an.
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.
[[["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-12-19 (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).\nYou can also see\n[Getting support](/kubernetes-engine/distributed-cloud/bare-metal/docs/getting-support) for more information about support resources, including the following:\n\n- [Requirements](/kubernetes-engine/distributed-cloud/bare-metal/docs/getting-support#intro-support) for opening a support case.\n- [Tools](/kubernetes-engine/distributed-cloud/bare-metal/docs/getting-support#support-tools) to help you troubleshoot, such as your environment configuration, logs, and metrics.\n- Supported [components](/kubernetes-engine/distributed-cloud/bare-metal/docs/getting-support#what-we-support)."]]
