Fehlerbehebung

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

Prüfen Sie bei der Fehlerbehebung in Cloud Run for Anthos, 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 in Cloud Run for Anthos.

Weitere Informationen zu den bekannten Problemen in Cloud Run for Anthos und deren Behebung finden Sie auf der Seite Bekannte Probleme.

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 Cloud Run for Anthos-Seite 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 Cloud Run for Anthos-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:

Weitere Informationen zu Statusbedingungen finden Sie unter Knative Error Signaling.

Routenstatus überprüfen

Jeder Cloud Run for Anthos-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:

  • 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 Error-Bedingungen und Berichterstellung.

Ingress-Status prüfen

Cloud Run for Anthos verwendet den Load-Balancer-Kubernetes-Dienst istio-ingress, der für die Verarbeitung des eingehenden Traffics von außerhalb des Clusters zuständig ist.

Verwenden Sie zum Abrufen der externen IP-Adresse Ihres Ingress

kubectl get svc istio-ingress -n gke-system

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

Überarbeitungsstatus prüfen

Führen Sie den folgenden Befehl aus, um die neueste Überarbeitung für Ihren Cloud Run for Anthos-Dienst abzurufen:

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

Führen Sie den folgenden Befehl aus, um den Status einer bestimmten Cloud Run for Anthos-Überarbeitung 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.

So rufen Sie die externe IP-Adresse für das Istio-Ingress-Gateway ab:

kubectl get svc istio-ingress -n gke-system

Die resultierende Ausgabe sieht in etwa so aus:

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

Die EXTERNAL-IP für den Load-Balancer ist die zu verwendende IP-Adresse.

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-ingress -n gke-system

Dies ergibt eine Ausgabe, die in etwa so aussieht:

Name:                     istio-ingress
Namespace:                gke-system
Labels:                   addonmanager.kubernetes.io/mode=Reconcile
                          app=istio-ingress
                          chart=gateways-1.0.3
                          heritage=Tiller
                          istio=ingress-gke-system
                          k8s-app=istio
                          kubernetes.io/cluster-service=true
                          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=ingressgateway,istio=ingress-gke-system,release=istio
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 von IN_USE_ADDRESSES überschritten wurde, können Sie in der Google Cloud Console auf der Seite „IAM & amp; Verwaltung“ ein zusätzliches Kontingent anfordern.

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

Fehler bei verwalteten TLS-Problemen beheben

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

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 Sie

    • 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 Detaillierte Mitteilung Anleitung zur Fehlerbehebung
Fehler bei DNS Der DNS-Eintrag ist nicht ordnungsgemäß konfiguriert. Die Domain [XXX] muss der IP-Adresse XX.XX.XX.XX zugeordnet werden. Folgen Sie der Anleitung, um den DNS-Eintrag richtig zu konfigurieren.
Ratenlimit überschritten acme: urn:ietf:params:acme:error:rateLimited: Fehler beim Erstellen des neuen Auftrags

:: Zu viele Zertifikate für einen bestimmten Satz an Domains wurden bereits ausgestellt:

test.beispiel.de:

siehe https://letsencrypt.org/docs/rate-limits/

Wenden Sie sich an Let's Encrypt, um Ihr Zertifikatkontingent für diesen Host zu erhöhen.
UngültigerDomainMappingName Der DomainMapping-Name %s darf nicht mit dem Routen-URL-Host %s identisch sein. 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.
Fehler bei der Auslieferung Die HTTP01-Anfrage konnte nicht verarbeitet werden. Dieser Fehler kann auftreten, wenn der istio-ingress-Dienst die Anfrage von Let's Encrypt zur Validierung der Domaininhaberschaft nicht verarbeiten kann.
  1. Achten Sie darauf, dass der istio-ingress-Dienst über das öffentliche Internet zugänglich ist, ohne Virtual Private Cloud zu verwenden.
  2. Achte darauf, dass dein istio-ingress-Dienst Anfragen von der URL http://DOMAIN/.well-known/acme-challenge/... akzeptiert, wobei DOMAIN die Domain ist, die validiert werden soll.

Systemfehler

Fehlercode Detaillierte Mitteilung Anleitung zur Fehlerbehebung
OrderErrored (Bestellfehler)

Authentifizierungsfehler

Challenge-Fehler

Diese drei Arten von Fehlern treten auf, wenn die Bestätigung der Domaininhaberschaft durch „Let's Encrypt“ fehlschlägt.

Diese Fehler sind in der Regel vorübergehend und werden von Cloud Run for Anthos wiederholt.

Die Wiederholungsverzögerung ist exponentiell und 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

ACMEAPIFehlgeschlagen Diese Art von Fehler tritt auf, wenn LetsEncrypt nicht von Cloud Run for Anthos aufgerufen werden kann. Dieser Fehler sind in der Regel vorübergehend und wird von Cloud Run for Anthos wiederholt.

Wenn Sie den Fehler manuell wiederholen möchten, löschen Sie den fehlgeschlagenen Auftrag manuell.

kubectl delete order DOMAIN -n NAMESPACE

Unbekannter Fehler 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 Sie

  • 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.

LetsEncrypt-Kontingent überschreiten

Prüfen Sie den DomainMapping-Status. Wenn Sie Ihr LetsEncrypt-Kontingent überschreiten, wird im DomainMapping eine Fehlermeldung wie die folgende angezeigt:

acme: urn:ietf:params:acme:error:rateLimited: Error creating new order
:: too many certificates already issued for exact set of domains:
test.example.com:
see https://letsencrypt.org/docs/rate-limits/'

Informationen zum Erhöhen des Zertifikatskontingents finden Sie in der LetsEncrypt-Dokumentation zu den Ratenbegrenzungen.

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.example.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 istio-ingress-Dienstes unter gke-system zuzuordnen. Führen Sie den folgenden Befehl aus, um den DNS-Eintrag zu prüfen:

    host DOMAIN

  3. Führen Sie den folgenden Befehl aus, um die externe IP-Adresse des Dienstes istio-ingress unter gke-system zu prüfen:

    kubectl get svc istio-ingress -n gke-system

    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. Rufen Sie mit dem folgenden Befehl die externe IP-Adresse des Dienstes istio-ingress unter gke-system ab: 
      kubectl get svc istio-ingress -n gke-system

    2. Prüfen Sie den DNS-Eintrag für die Domain mit dem folgenden Befehl: 

      host DOMAIN

      Wenn die IP-Adresse des DNS-Eintrags nicht mit der externen IP-Adresse des istio-ingress-Dienstes unter gke-system ü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 Sie

    • 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 die Bereitstellung von istio-pilot im Namespace gke-system möglicherweise neu starten. Dieser Fehler tritt in Kubernetes 1.14 häufiger auf und ist möglich, wenn die Dienste erstellt werden, bevor istio_pilot 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 istio-pilot -n gke-system --replicas=0
kubectl scale deployment istio-pilot -n gke-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 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 Workload Identity aktivieren ausführen.

WebSockets mit benutzerdefinierten Domains verwenden

Standardmäßig sind WebSockets für benutzerdefinierte Domainzuordnungen deaktiviert.

Zum Aktivieren von WebSockets für Ihre benutzerdefinierten Domains führen Sie den folgenden Befehl aus. Damit wird ein Istio EnvoyFilter-Objekt mit allow_connect: true erstellt:

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: allowconnect-cluster-local-gateway-tb
  namespace: gke-system
spec:
  workloadSelector:
    labels:
      istio: ingress-gke-system
  configPatches:
  - applyTo: NETWORK_FILTER
    match:
      listener:
        portNumber: 8081
        filterChain:
          filter:
            name: "envoy.http_connection_manager"
    patch:
      operation: MERGE
      value:
        typed_config:
          "@type": "type.googleapis.com/envoy.config.filter.network.http_connection_manager.v2.HttpConnectionManager"
          http2_protocol_options:
            allow_connect: true
EOF