Fehlerbehebung

Auf dieser Seite werden Strategien zur Fehlerbehebung sowie Lösungen für häufig auftretende Probleme beschrieben.

Prüfen Sie bei der Fehlerbehebung für Knative Serving, ob Sie das Container-Image lokal ausführen können.

Wenn Ihre Anwendung nicht lokal ausgeführt wird, müssen Sie den Fehler diagnostizieren und beheben. Verwenden Sie für die Fehlerbehebung in einem bereitgestellten Projekt Cloud Logging.

In den folgenden Abschnitten finden Sie mögliche Lösungen zur Behebung von Fehlern bei Knative Serving.

Befehlszeilenausgabe prüfen

Wenn Sie die Google Cloud CLI verwenden, prüfen Sie in der Befehlsausgabe, ob das Deployment erfolgreich war. Wenn es beispielsweise fehlgeschlagen ist, sollten Sie eine Fehlermeldung sehen, in der die Ursache für den Fehler angegeben ist.

Deployment-Fehler sind meist auf ein falsch konfiguriertes Manifest oder einen falschen Befehl zurückzuführen. Die folgende Ausgabe besagt beispielsweise, dass die Summe des weitergeleiteten Traffics 100 % ergeben muss.

Error from server (InternalError): error when applying patch:</p><pre>{"metadata":{"annotations":{"kubectl.kubernetes.io/last-applied-configuration":"{\"apiVersion\":\"serving.knative.dev/v11\",\"kind\":\"Route\",\"metadata\":{\"annotations\":{},\"name\":\"route-example\",\"namespace\":\"default\"},\"spec\":{\"traffic\":[{\"configurationName\":\"configuration-example\",\"percent\":50}]}}\n"}},"spec":{"traffic":[{"configurationName":"configuration-example","percent":50}]}}
to:
&{0xc421d98240 0xc421e77490 default route-example STDIN 0xc421db0488 264682 false}
for: "STDIN": Internal error occurred: admission webhook "webhook.knative.dev" denied the request: mutation failed: The route must have traffic percent sum equal to 100.
ERROR: Non-zero return code '1' from command: Process exited with status 1

Logs des Dienstes prüfen

Sie können Cloud Logging oder die Seite „Knative-Bereitstellung“ in der Google Cloud Console verwenden, um Anfrage- und Containerlogs zu prüfen. Ausführliche Informationen finden Sie unter Logs aufzeichnen und ansehen.

Wenn Sie Cloud Logging verwenden, filtern Sie nach der Ressource Kubernetes-Container.

Dienststatus prüfen

Führen Sie den folgenden Befehl aus, um den Status eines bereitgestellten Knative Serving-Dienstes abzurufen:

gcloud run services describe SERVICE

Sie können --format yaml(status) oder --format json(status) hinzufügen, um den vollständigen Status zu erhalten. Beispiel:

gcloud run services describe SERVICE --format 'yaml(status)'

Die Bedingungen in status können Ihnen dabei helfen, die Fehlerursache zu ermitteln. Bedingungen können True, False oder Unknown enthalten:

• Ready: True gibt an, dass der Dienst konfiguriert ist und Traffic empfangen kann.
• ConfigurationReady True gibt an, dass die zugrunde liegende Konfiguration bereit ist. Für False oder Unknown sollten Sie den Status der neuesten Überarbeitung aufrufen.
• RoutesReady True gibt an, dass die zugrunde liegende Route bereit ist. Für False oder Unknown sollten Sie den Status der Route aufrufen.

Weitere Informationen zu Statusbedingungen finden Sie unter Knative Error Signaling.

Routenstatus überprüfen

Jeder Knative Serving-Dienst verwaltet eine Route, die den aktuellen Routingstatus anhand der Überarbeitungen des Dienstes darstellt.

Sie können den Gesamtstatus der Route anhand des Dienststatus prüfen.

gcloud run services describe SERVICE --format 'yaml(status)'

Die Bedingung RoutesReady in status zeigt den Status der Route an.

Mit folgendem Befehl können Sie den Routenstatus genauer diagnostizieren:

kubectl get route SERVICE -o yaml

Die Bedingungen in status geben den Grund für den Fehler an. Dazu gehören:

• Ready gibt an, ob der Dienst konfiguriert ist und über verfügbare Back-Ends verfügt. Wenn dieser Wert true lautet, ist die Route richtig konfiguriert.

• AllTrafficAssigned gibt an, ob der Dienst ordnungsgemäß konfiguriert ist und verfügbare Back-Ends hat. Wenn der status dieser Bedingung nicht True ist:

  • Prüfen Sie, ob die Trafficaufteilung zwischen den Überarbeitungen für Ihren Dienst 100 % ergibt:

    gcloud run services describe SERVICE

    Passen Sie andernfalls die Trafficaufteilung mit dem Befehl gcloud run services update-traffic an.

  • Sehen Sie sich den Überarbeitungsstatus an, um Überarbeitungen zu ermitteln, die Traffic erhalten.

• IngressReady gibt an, ob Ingress bereit ist. Wenn der status dieser Bedingung nicht True ist, sollte der Ingress-Status geprüft werden.

• CertificateProvisioned gibt an, ob Knative-Zertifikate bereitgestellt wurden. Wenn der status dieser Bedingung nicht True ist, versuchen Sie, die Probleme mit verwalteten TLS-Problemen zu beheben.

Weitere Informationen zu Statusbedingungen finden Sie unter Knative-Fehlerbedingungen und -Berichterstellung.

Ingress-Status prüfen

Knative Serving verwendet den Load-Balancer-Dienst istio-ingressgateway, der für die Verarbeitung des eingehenden Traffics von außerhalb des Clusters zuständig ist.

Führen Sie den folgenden Befehl aus, um die externe IP-Adresse für den Load-Balancer abzurufen:

kubectl get svc istio-ingressgateway -n ASM-INGRESS-NAMESPACE

Ersetzen Sie ASM-INGRESS-NAMESPACE durch den Namespace, in dem sich der Cloud Service Mesh-Ingress befindet. Geben Sie istio-system an, wenn Sie Cloud Service Mesh mit der Standardkonfiguration installiert haben.

Die Ausgabe sieht dann ungefähr so aus:

NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP  PORT(S)
istio-ingressgateway   LoadBalancer   XX.XX.XXX.XX   pending      80:32380/TCP,443:32390/TCP,32400:32400/TCP

Dabei ist der Wert EXTERNAL-IP Ihre externe IP-Adresse für den Load-Balancer.

Wenn die EXTERNAL-IP pending ist, finden Sie weitere Informationen unten unter EXTERNAL-IP ist lange Zeit pending.

Überarbeitungsstatus prüfen

Führen Sie folgenden Befehl aus, um die neueste Überarbeitung für Ihren Knative Serving-Dienst abzurufen:

gcloud run services describe SERVICE --format='value(status.latestCreatedRevisionName)'

Führen Sie den folgenden Befehl aus, um den Status einer bestimmten Knative Serving-Version abzurufen:

gcloud run revisions describe REVISION

Sie können --format yaml(status) oder --format json(status) hinzufügen, um den vollständigen Status zu erhalten:

gcloud run revisions describe REVISION --format yaml(status)

Die Bedingungen in status geben den Grund für den Fehler an. Dazu gehören:

• Ready gibt an, ob die Laufzeitressourcen bereit sind. Wenn dieser Wert true ist, ist die Überarbeitung richtig konfiguriert.
• ResourcesAvailable gibt an, ob die zugrunde liegenden Kubernetes-Ressourcen bereitgestellt wurden. Wenn der status dieser Bedingung nicht True ist, sollte der Pod-Status geprüft werden.
• ContainerHealthy gibt an, ob die Überarbeitungsprüfung abgeschlossen ist. Wenn der status dieser Bedingung nicht True ist, sollte der Pod-Status geprüft werden.
• Active gibt an, ob die Überarbeitung Traffic erhält.

Wenn eine der status-Werte der Bedingung nicht True ist, prüfen Sie den Pod-Status.

Pod-Status prüfen

So rufen Sie die Pods für alle Ihre Deployments ab:

kubectl get pods

Hiermit sollten alle Pods mit einer kurzen Statusangabe aufgeführt werden. Beispiel:

NAME                                                      READY     STATUS             RESTARTS   AGE
configuration-example-00001-deployment-659747ff99-9bvr4   2/2       Running            0          3h
configuration-example-00002-deployment-5f475b7849-gxcht   1/2       CrashLoopBackOff   2          36s

Wählen Sie einen Pod aus und rufen Sie mit dem folgenden Befehl die detaillierten Informationen zu seinem status auf. Nützliche Felder sind conditions und containerStatuses:

kubectl get pod POD-NAME -o yaml

EXTERNAL-IP hat lange den Status <pending>

Sie erhalten mitunter nicht sofort nach der Erstellung eines Clusters eine externe IP-Adresse. Stattdessen wird der Status pending angezeigt. Sie sehen dies beispielsweise mit folgendem Befehl.

Führen Sie den folgenden Befehl aus, um die externe IP-Adresse für den Load-Balancer abzurufen:

kubectl get svc istio-ingressgateway -n ASM-INGRESS-NAMESPACE

Ersetzen Sie ASM-INGRESS-NAMESPACE durch den Namespace, in dem sich der Cloud Service Mesh-Ingress befindet. Geben Sie istio-system an, wenn Sie Cloud Service Mesh mit der Standardkonfiguration installiert haben.

Die Ausgabe sieht dann ungefähr so aus:

NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP  PORT(S)
istio-ingressgateway   LoadBalancer   XX.XX.XXX.XX   pending      80:32380/TCP,443:32390/TCP,32400:32400/TCP

Dabei ist der Wert EXTERNAL-IP Ihre externe IP-Adresse für den Load-Balancer.

Dies bedeutet möglicherweise, dass das Kontingent an externen IP-Adressen in Google Cloud aufgebraucht ist. Die mögliche Ursache können Sie mit folgendem Befehl prüfen:

kubectl describe svc istio-ingressgateway -n INGRESS_NAMESPACE

Dabei ist INGRESS_NAMESPACE der Namespace von ASM-Ingress, der standardmäßig „istio-system“ ist. Dies ergibt eine Ausgabe ähnlich der folgenden:

Name:                     istio-ingressgateway
Namespace:                INGRESS_NAMESPACE
Labels:                   app=istio-ingressgateway
                          istio=ingressgateway
                          istio.io/rev=asm-1102-3
                          operator.istio.io/component=IngressGateways
                          operator.istio.io/managed=Reconcile
                          operator.istio.io/version=1.10.2-asm.3
                          release=istio
Annotations:              kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"addonmanager.kubernetes.io/mode":"Reconcile","app":"istio-ingressgateway","...
Selector:                 app=istio-ingressgateway,istio=ingressgateway
Type:                     LoadBalancer
IP:                       10.XX.XXX.XXX
LoadBalancer Ingress:     35.XXX.XXX.188
Port:                     http2  80/TCP
TargetPort:               80/TCP
NodePort:                 http2  31380/TCP
Endpoints:                XX.XX.1.6:80
Port:                     https  443/TCP
TargetPort:               443/TCP
NodePort:                 https  3XXX0/TCP
Endpoints:                XX.XX.1.6:XXX
Port:                     tcp  31400/TCP
TargetPort:               3XX00/TCP
NodePort:                 tcp  3XX00/TCP
Endpoints:                XX.XX.1.6:XXXXX
Port:                     tcp-pilot-grpc-tls  15011/TCP
TargetPort:               15011/TCP
NodePort:                 tcp-pilot-grpc-tls  32201/TCP
Endpoints:                XX.XX.1.6:XXXXX
Port:                     tcp-citadel-grpc-tls  8060/TCP
TargetPort:               8060/TCP
NodePort:                 tcp-citadel-grpc-tls  31187/TCP
Endpoints:                XX.XX.1.6:XXXX
Port:                     tcp-dns-tls  853/TCP
TargetPort:               XXX/TCP
NodePort:                 tcp-dns-tls  31219/TCP
Endpoints:                10.52.1.6:853
Port:                     http2-prometheus  15030/TCP
TargetPort:               XXXXX/TCP
NodePort:                 http2-prometheus  30944/TCP
Endpoints:                10.52.1.6:15030
Port:                     http2-grafana  15031/TCP
TargetPort:               XXXXX/TCP
NodePort:                 http2-grafana  31497/TCP
Endpoints:                XX.XX.1.6:XXXXX
Session Affinity:         None
External Traffic Policy:  Cluster
Events:
  Type    Reason                Age                  From                Message
  ----    ------                ----                 ----                -------
  Normal  EnsuringLoadBalancer  7s (x4318 over 15d)  service-controller  Ensuring load balancer

Wenn die Ausgabe darauf hindeutet, dass das Kontingent der IN_USE_ADDRESSES überschritten wurde, können Sie in der Google Cloud Console auf der Seite „IAM & Verwaltung“ ein zusätzliches Kontingent anfordern.

Das Gateway wiederholt die Anfrage, bis die externe IP-Adresse zugewiesen ist. Dies kann einige Minuten dauern.

Fehlerbehebung bei benutzerdefinierten Domains und verwalteten TLS

Führen Sie diese Schritte zur Fehlerbehebung aus, um allgemeine Probleme mit benutzerdefinierten Domains und dem Feature Verwaltete TLS-Zertifikate zu beheben.

Benutzerdefinierte Domains für private, interne Netzwerke

Wenn Sie Ihrem Knative Serving-Cluster oder ‑Diensten innerhalb eines privaten, internen Netzwerks eine benutzerdefinierte Domain zugewiesen haben, müssen Sie verwaltete TLS-Zertifikate deaktivieren, da Ihre Domainenkonfiguration sonst nicht den Status ready erreicht. Standardmäßig kann der interne Load-Balancer nicht extern mit der Zertifizierungsstelle kommunizieren.

Status einer bestimmten Domainzuordnung prüfen

So prüfen Sie den Status einer bestimmten Domainzuordnung:

1. Führen Sie diesen Befehl aus:

   gcloud run domain-mappings describe --domain DOMAIN --namespace NAMESPACE

   Ersetzen

   • DOMAIN durch den Namen der von Ihnen verwendeten Domain.
   • NAMESPACE durch den Namespace, den Sie für die Domainzuordnung verwenden.

2. Untersuchen Sie in den yaml-Ergebnissen dieses Befehls die Bedingung des Felds CertificateProvisioned, um die Art des Fehlers zu bestimmen.

3. Wenn ein Fehler angezeigt wird, sollte dieser mit einem der Fehler in den folgenden Tabellen übereinstimmen. Befolgen Sie die Vorschläge in den Tabellen, um das Problem zu beheben.

Fehler bei der Nutzerkonfiguration

Fehlercode	Details
DNSErrored	Meldung: Der DNS-Eintrag ist nicht ordnungsgemäß konfiguriert. Die Domain [XXX] muss der IP-Adresse XX.XX.XX.XX zugeordnet werden. Folgen Sie der bereitgestellten Anleitung, um Ihren DNS-Eintrag ordnungsgemäß zu konfigurieren.
RateLimitExceeded	Meldung: acme: urn:ietf:params:acme:error:rateLimited: Fehler beim Erstellen von neuem Auftrag :: Es wurden bereits zu viele Zertifikate für eine genaue Gruppe von Domains ausgestellt: test.your-domain.com: Siehe https://letsencrypt.org/docs/rate-limits/ Das LetsEncrypt-Kontingent wurde überschritten. Sie müssen Ihr LetsEncrypt-Zertifikatskontingent für diesen Host erhöhen.
InvalidDomainMappingName	Meldung: DomainMapping-Name %s darf nicht mit dem Routen-URL-Host %s übereinstimmen. Der DomainMapping-Name darf nicht genau mit dem Host der Route übereinstimmen, der er zugeordnet ist. Verwenden Sie für Ihren DomainMapping-Namen eine andere Domain.
ChallengeServingErrored	Meldung: Das System konnte die HTTP01-Anfrage nicht verarbeiten. Dieser Fehler kann auftreten, wenn der istio-ingressgateway-Dienst die Anfrage von LetsEncrypt zur Bestätigung der Domaininhaberschaft nicht verarbeiten kann. Achten Sie darauf, dass der istio-ingressgateway-Dienst über das öffentliche Internet zugänglich ist, ohne Virtual Private Cloud zu verwenden. Achten Sie außerdem darauf, dass Ihr istio-ingressgateway-Dienst Anfragen von der URL http://DOMAIN/.well-known/acme-challenge/... akzeptiert, wobei DOMAIN die Domain ist, die validiert werden soll.

Systemfehler

Fehlercode	Details
OrderErrored AuthzErrored ChallengeErrored	Diese drei Arten von Fehlern treten auf, wenn die Bestätigung der Domaininhaberschaft durch LetsEncrypt fehlschlägt. Diese Fehler sind in der Regel vorübergehend und werden von Knative Serving wiederholt. Die Wiederholungsverzögerung ist exponentiell. Sie beträgt mindestens 8 Sekunden und maximal 8 Stunden. Wenn Sie den Fehler manuell wiederholen möchten, können Sie den fehlgeschlagenen Auftrag manuell löschen. kubectl delete order DOMAIN -n NAMESPACE
ACMEAPIFailed	Diese Art von Fehler tritt auf, wenn LetsEncrypt nicht von Knative Serving aufgerufen werden kann. Dieser Fehler ist in der Regel vorübergehend und wird von Knative Serving wiederholt. Wenn Sie den Fehler manuell wiederholen möchten, löschen Sie den fehlgeschlagenen Auftrag manuell. kubectl delete order DOMAIN -n NAMESPACE
UnknownErrored	Dieser Fehler weist auf einen unbekannten Systemfehler hin, der nur selten im GKE-Cluster auftritt. Wenden Sie sich in diesem Fall an den Cloud-Support, um Hilfe beim Debugging zu erhalten.

Bestellstatus prüfen

Der Auftragsstatus zeichnet den Prozess der Interaktion mit LetsEncrypt auf und kann daher zur Fehlerbehebung bei Problemen mit LetsEncrypt verwendet werden. Prüfen Sie gegebenenfalls den Auftragsstatus mit folgendem Befehl:

kubectl get order DOMAIN -n NAMESPACE -oyaml

Ersetzen

• DOMAIN durch den Namen der von Ihnen verwendeten Domain.
• NAMESPACE durch den Namespace, den Sie für die Domainzuordnung verwenden.

Die Ergebnisse enthalten die ausgestellten Zertifikate und weitere Informationen, falls der Auftrag erfolgreich war.

Zeitüberschreitung des Auftrags

Das Zeitlimit eines Order-Objekts wird nach 20 Minuten überschritten, wenn weiterhin keine Zertifikate abgerufen werden können.

1. Prüfen Sie den DomainMapping-Status. Suchen Sie bei einer Zeitüberschreitung in der Statusausgabe nach einer Fehlermeldung wie dieser:

   order (test.your-domain.com) timed out (20.0 minutes)

2. Eine häufige Ursache dieses Problems ist, dass Ihr DNS-Eintrag nicht ordnungsgemäß konfiguriert ist, um die von Ihnen verwendete Domain der IP-Adresse des Ingress-Dienstes zuzuordnen. Führen Sie den folgenden Befehl aus, um den DNS-Eintrag zu prüfen:

   host DOMAIN

3. Prüfen Sie die externe IP-Adresse Ihres Ingress-Load-Balancers:

   Führen Sie den folgenden Befehl aus, um die externe IP-Adresse für den Load-Balancer abzurufen:

   kubectl get svc istio-ingressgateway -n ASM-INGRESS-NAMESPACE

   Ersetzen Sie ASM-INGRESS-NAMESPACE durch den Namespace, in dem sich der Cloud Service Mesh-Ingress befindet. Geben Sie istio-system an, wenn Sie Cloud Service Mesh mit der Standardkonfiguration installiert haben.

   Die Ausgabe sieht dann ungefähr so aus:

   NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP  PORT(S)
   istio-ingressgateway   LoadBalancer   XX.XX.XXX.XX   pending      80:32380/TCP,443:32390/TCP,32400:32400/TCP

   Dabei ist der Wert EXTERNAL-IP Ihre externe IP-Adresse für den Load-Balancer.

   Wenn die externe IP-Adresse Ihrer Domain nicht mit der Ingress-IP-Adresse übereinstimmt, konfigurieren Sie Ihren DNS-Eintrag so, dass die richtige IP-Adresse zugeordnet wird.

4. Führen Sie, nachdem der (aktualisierte) DNS-Eintrag wirksam wird, den folgenden Befehl aus, um das Order-Objekt zu löschen und ein neues TLS-Zertifikat anzufordern:

   kubectl delete order DOMAIN -n NAMESPACE

   Ersetzen

   • DOMAIN durch den Namen der von Ihnen verwendeten Domain.
   • NAMESPACE durch den von Ihnen verwendeten Namespace.

Autorisierungsfehler

Autorisierungsfehler können auftreten, wenn ein DNS-Eintrag nicht rechtzeitig global weitergegeben wird. Daher kann LetsEncrypt die Inhaberschaft der Domain nicht bestätigen.

1. Auftragsstatus prüfen Suchen Sie unter dem Statusfeld acmeAuthorizations nach dem Link „authz“. Die URL sollte so aussehen:

   https://acme-v02.api.letsencrypt.org/acme/authz-v3/1717011827

2. Öffnen Sie den Link. Wenn eine Meldung wie die folgende angezeigt wird:

   urn:ietf:params:acme:error:dns

   Dann ist das Problem auf eine unvollständige DNS-Weitergabe zurückzuführen.

3. So beheben Sie den DNS-Weiterleitungsfehler:

   1. Prüfen Sie die externe IP-Adresse Ihres Ingress-Load-Balancers:

      Führen Sie den folgenden Befehl aus, um die externe IP-Adresse für den Load-Balancer abzurufen:

      kubectl get svc istio-ingressgateway -n ASM-INGRESS-NAMESPACE

      Ersetzen Sie ASM-INGRESS-NAMESPACE durch den Namespace, in dem sich der Cloud Service Mesh-Ingress befindet. Geben Sie istio-system an, wenn Sie Cloud Service Mesh mit der Standardkonfiguration installiert haben.

      Die Ausgabe sieht dann ungefähr so aus:

      NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP  PORT(S)
      istio-ingressgateway   LoadBalancer   XX.XX.XXX.XX   pending      80:32380/TCP,443:32390/TCP,32400:32400/TCP

      Dabei ist der Wert EXTERNAL-IP Ihre externe IP-Adresse für den Load-Balancer.

   2. Prüfen Sie Ihren DNS-Eintrag für die Domain, indem Sie den folgenden Befehl ausführen:

      host DOMAIN

      Wenn die IP-Adresse des DNS-Eintrags nicht mit der externen IP-Adresse des Ingress-Load-Balancer übereinstimmt, konfigurieren Sie Ihren DNS-Eintrag so, dass die Domain des Nutzers der externen IP zugeordnet wird.

   3. Führen Sie, nachdem der (aktualisierte) DNS-Eintrag wirksam wird, den folgenden Befehl aus, um das Order-Objekt zu löschen und ein neues TLS-Zertifikat anzufordern:

      kubectl delete order DOMAIN -n NAMESPACE

   Ersetzen

   • DOMAIN durch den Namen der von Ihnen verwendeten Domain.
   • NAMESPACE durch den Namespace, den Sie für die Domainzuordnung verwenden.

Fehler bei der Bereitstellung in einem privaten Cluster: Fehler beim Aufrufen des Webhooks

Wenn bei der Bereitstellung in einem privaten Cluster die folgende Fehlermeldung angezeigt wird, ist Ihre Firewall möglicherweise nicht richtig eingerichtet:

Error: failed calling webhook "webhook.serving.knative.dev": Post
https://webhook.knative-serving.svc:443/?timeout=30s: context deadline exceeded (Client.Timeout
exceeded while awaiting headers)

Informationen zu Firewall-Änderungen, die zur Unterstützung der Bereitstellung in einem privaten Cluster erforderlich sind, finden Sie unter Bereitstellungen in einem privaten Cluster aktivieren.

Dienststatus „IngressNotConfigured“ wird angezeigt

Wenn IngressNotConfigured in Ihrem Dienststatus angezeigt wird, müssen Sie möglicherweise das Deployment istiod im Namespace istio-system neu starten, wenn Sie die Cloud Service Mesh auf Clusterebene verwenden. Dieser Fehler tritt in Kubernetes 1.14 häufiger auf und ist möglich, wenn die Dienste erstellt werden, bevor istiod mit dem Abgleich von VirtualServices und dem Übertragen der Envoy-Konfiguration an die Ingress-Gateways beginnen kann.

Zum Beheben dieses Problems skalieren Sie die Bereitstellung herunter und dann wieder mit Befehlen wie den folgenden horizontal:

kubectl scale deployment istiod -n istio-system --replicas=0
kubectl scale deployment istiod -n istio-system --replicas=1

Fehlende Messwerte zur Anzahl der Anfragen und zur Anfragelatenz

Ihr Dienst kann keine Messwerte für die Anzahl der Überarbeitungsanfragen und die Anfragelatenz melden, wenn Sie Workload Identity Federation for GKE aktiviert und dem von Ihrem Dienst verwendeten Dienstkonto nicht bestimmte Berechtigungen gewährt haben.

Sie können das Problem beheben, indem Sie die Schritte im Abschnitt Messwerte in einem Cluster mit der Workload Identity Federation for GKE aktivieren ausführen.