Auf dieser Seite werden Strategien zur Fehlerbehebung sowie Lösungen für häufig auftretende Probleme erläutert.
Prüfen Sie bei der Fehlerbehebung bei der Knative-Bereitstellung, 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 Fehlerbehebung bei der Bereitstellung mit Knative.
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 Knative-Bereitstellungsseite 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-Bereitstellungsdienstes 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ürFalse
oderUnknown
sollten Sie den Status der neuesten Überarbeitung aufrufen. - RoutesReady
True
gibt an, dass die zugrunde liegende Route bereit ist. FürFalse
oderUnknown
sollten Sie den Status der Route aufrufen.
Weitere Informationen zu Statusbedingungen finden Sie unter Knative Error Signaling.
Routenstatus überprüfen
Jeder Knative-Bereitstellungsdienst verwaltet eine Route, die den aktuellen Routingstatus für die Versionen 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 nichtTrue
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 nichtTrue
ist, sollte der Ingress-Status geprüft werden.CertificateProvisioned gibt an, ob Knative-Zertifikate bereitgestellt wurden. Wenn der
status
dieser Bedingung nichtTrue
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
Die Knative-Bereitstellung verwendet einen Load-Balancer-Dienst namens istio-ingressgateway
, der für die Verarbeitung von eingehendem Traffic von außerhalb des Clusters verantwortlich 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 Anthos Service Mesh-Ingress befindet. Geben Sie istio-system
an, wenn Sie Anthos 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 den folgenden Befehl aus, um die neueste Version für Ihren Knative-Bereitstellungsdienst abzurufen:
gcloud run services describe SERVICE --format='value(status.latestCreatedRevisionName)'
Führen Sie den folgenden Befehl aus, um den Status einer bestimmten Knative-Bereitstellungsversion 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 nichtTrue
ist, sollte der Pod-Status geprüft werden. - ContainerHealthy gibt an, ob die Überarbeitungsprüfung abgeschlossen ist.
Wenn der
status
dieser Bedingung nichtTrue
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 Anthos Service Mesh-Ingress befindet. Geben Sie istio-system
an, wenn Sie Anthos 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_NAMESPACEDabei 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 hinweist, dass das Kontingent von 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-Bereitstellungscluster oder Ihren Knative-Diensten in einem privaten, internen Netzwerk eine benutzerdefinierte Domain zugeordnet haben, müssen Sie verwaltete TLS-Zertifikate deaktivieren. Andernfalls erreicht Ihre Domainkonfiguration den Status ready
nicht. 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:
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.
Untersuchen Sie in den
yaml
-Ergebnissen dieses Befehls die Bedingung des FeldsCertificateProvisioned
, um die Art des Fehlers zu bestimmen.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 den DNS-Eintrag richtig 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 | Nachricht: Das System konnte die HTTP01-Anfrage nicht verarbeiten.
Dieser Fehler kann auftreten, wenn der
|
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übergehende Fehler und werden von Knative erneut ausgeführt. 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 die fehlgeschlagene Bestellung manuell löschen.
|
ACMEAPIFailed | Diese Art von Fehler tritt auf, wenn „Let's Encrypt“ von der Knative-Bereitstellung nicht aufgerufen werden kann. Dies ist in der Regel ein vorübergehender Fehler, der von der Bereitstellung durch Knative wiederholt wird.
Wenn Sie den Fehler manuell wiederholen möchten, löschen Sie die fehlgeschlagene Bestellung manuell.
|
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 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.
Zeitüberschreitung des Auftrags
Das Zeitlimit eines Order-Objekts wird nach 20 Minuten überschritten, wenn weiterhin keine Zertifikate abgerufen werden können.
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)
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
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 Anthos Service Mesh-Ingress befindet. Geben Sie
istio-system
an, wenn Sie Anthos 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.
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 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.
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
Ö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.
So beheben Sie den DNS-Weiterleitungsfehler:
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 Anthos Service Mesh-Ingress befindet. Geben Sie
istio-system
an, wenn Sie Anthos 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.
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 Ingress-Load-Balancer übereinstimmt, konfigurieren Sie Ihren DNS-Eintrag so, dass die Domain des Nutzers der externen IP zugeordnet wird.
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 möglicherweise das Deployment istiod
im Namespace istio-system
neu starten, wenn Sie die Anthos 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 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.