Auf dieser Seite sind bekannte Probleme von Cloud Run for Anthos aufgeführt. Informationen zu bekannten Sicherheitslücken finden Sie unter Best Practices für die Sicherheit.
Außerdem können Sie in der öffentlichen Problemverfolgung prüfen, ob Probleme vorhanden sind, und neue Probleme eröffnen.
Auf der Seite Fehlerbehebung finden Sie Strategien zur Fehlerbehebung sowie Lösungen für häufig auftretende Fehler.
Mit RevisionMissing
hängende Dienste wegen fehlender MutatingWebhookConfiguration
Das Erstellen eines neuen Dienstes oder einer neuen Dienstüberarbeitung kann aufgrund einer fehlenden Webhook-Konfiguration im Status "RevisionMissing" hängen bleiben. Sie können dies mit folgendem Befehl prüfen:
kubectl get mutatingwebhookconfiguration webhook.serving.knative.dev
das die Rückgabe
kmutatingwebhookconfigurations.admissionregistration.k8s.io "webhook.serving.knative.dev" not found`
Temporäre Problemumgehung
Bis dieses Problem in einer künftigen Version behoben wird, können Sie es so umgehen:
Starten Sie den Webhook-Pod neu, um
MutatingWebhookConfiguration
neu zu erstellen:kubectl delete pod -n knative-serving -lapp=webhook kubectl get mutatingwebhookconfiguration --watch
Starten Sie die Controller neu:
kubectl delete pod -n gke-system -listio=pilot kubectl delete pod -n knative-serving -lapp=controller
Stellen Sie eine neue Überarbeitung für jeden Dienst mit dem Problem
RevisionMissing
bereit:gcloud run services update SERVICE --update-labels client.knative.dev/nonce=""
Ersetzen Sie dabei SERVICE durch den Namen des Dienstes.
Wiederholen Sie die obigen Schritte, wenn das Problem wieder auftritt, wenn Sie neue Überarbeitungen des Dienstes bereitstellen.
Zonale Cluster
Bei Verwendung eines zonalen Clusters mit Cloud Run for Anthos ist während der Clusterwartung kein Zugriff auf die Steuerungsebene möglich.
In diesem Zeitraum funktioniert Cloud Run for Anthos möglicherweise nicht wie erwartet. Für in diesem Cluster bereitgestellte Dienste gilt dann Folgendes:
- Werden nicht in der Cloud Console oder über die gcloud CLI angezeigt
- Sie können nicht gelöscht oder aktualisiert werden.
- Instanzen werden nicht automatisch skaliert, aber bestehende Instanzen können weiterhin neue Anfragen verarbeiten.
Zur Vermeidung dieser Probleme können Sie einen regionalen Cluster verwenden, der eine Steuerungsebene mit Hochverfügbarkeit gewährleistet.
Standardmäßiges Arbeitsspeicherlimit wird nicht über die Befehlszeile erzwungen
Wenn Sie die Befehlszeile zum Bereitstellen Ihrer Dienste verwenden, müssen Sie das Flag --memory
einfügen, um ein Speicherlimit für diesen Dienst festzulegen. Wenn Sie das Flag --memory
ausschließen, kann ein Dienst den gesamten verfügbaren Arbeitsspeicher auf dem Knoten verbrauchen, auf dem dieser Pod ausgeführt wird. Dies kann unerwartete Nebenwirkungen haben.
Bei der Bereitstellung über die Google Cloud Console wird der Standardwert 256M
verwendet, sofern kein anderer Wert angegeben ist.
Wenn Sie kein Standardlimit für jeden Dienst festlegen müssen, können Sie ein Standardarbeitsspeicherlimit für den Namespace definieren, in dem Sie diese Dienste bereitstellen. Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter Standardspeicherlimits konfigurieren.
Standard-CPU-Limit ist nicht aktiviert
Beim Deployment über die Befehlszeile oder die Console ist der Umfang der CPU, den ein Dienst nutzen kann, nicht definiert. Dadurch kann der Dienst die gesamte verfügbare CPU auf dem Knoten nutzen, auf dem er ausgeführt wird. Dies kann unerwartete Nebeneffekte haben.
Sie können dies umgehen und ein Standard-CPU-Limit für den Namespace festlegen, in dem Sie Dienste mit Cloud Run for Anthos bereitstellen. Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter Standard-CPU-Limits konfigurieren.
Hinweis: Standardmäßig erfordern Dienste, die mit Cloud Run for Anthos bereitgestellt werden, eine 400m
-CPU. Damit werden Instanzen eines Dienstes auf den Clusterknoten geplant.
Der Inhalt der Lese-/Schreibpunkte im Container ist immer leer.
Wenn ein Container Dateien oder Ordner in /var/log
(z. B. /var/log/nginx
) erstellt, sind diese Dateien oder Ordner beim Ausführen dieses Containers in Cloud Run for Anthos nicht sichtbar, da damit in /var/log
ein leeres Lese-/Schreibvolume bereitgestellt wurde. Dadurch wird Inhalt des zugrunde liegenden Containers ausgeblendet.
Wenn Ihr Dienst in ein Unterverzeichnis von /var/log
schreibt, muss der Dienst dafür sorgen, dass der Ordner zur Laufzeit vorhanden ist, bevor in den Ordner geschrieben wird. Es darf nicht davon ausgegangen werden, dass der Ordner aus dem Container-Image automatisch vorhanden ist.
Problemumgehung
Wenn Sie Ihren Cluster auf die GKE-Version 1.17 aktualisiert haben und Probleme mit dem Dienst-Deployment auftreten, müssen Sie den von DomainMapping generierten VirtualService löschen, da er mit dem neuen Controller nicht kompatibel ist. Nachdem Sie ihn gelöscht haben, erstellt der Controller einen kompatiblen VirtualService neu und löst damit das Problem beim Dienst-Deployment.
Mit den im Folgenden aufgeführten Befehlen löschen Sie den VirtualService, wobei der Name des VirtualService dem Ihrer DomainMapping entspricht.
Beispiel: foo.example.com
Führen Sie den folgenden Befehl aus, um alle DomainMappings aufzulisten:
kubectl get domainmapping --all-namespaces
Führen Sie den folgenden Befehl aus, um den angegebenen VirtualService zu löschen:
kubectl delete vs your-domain-mapping-name -n your-domain-mapping-namespace
Private Container-Images in Artifact Registry bereitstellen
Es gibt ein bekanntes Bereitstellungsproblem, das durch einen Authentifizierungsfehler zwischen Cloud Run for Anthos und Artifact Registry verursacht wird, wenn private Container-Images bereitgestellt werden. So lassen sich Probleme bei der Bereitstellung privater Images in Artifact Registry vermeiden:
Verwenden Sie den Image-Digest Ihrer privaten Container-Images, um einen Dienst bereitzustellen.
Erstellen und verwenden Sie eine
imagePullSecret
. Mit einemimagePullSecret
können Sie das Image-Tag Ihrer privaten Container-Images verwenden. Weitere Informationen finden Sie unter Private Container-Images aus anderen Container Registries bereitstellen.
Konfigurationsfehler bei Clustern, die auf Version 0.20.0-gke.6
aktualisiert wurden
Bei Clustern, die auf Version 0.20.0-gke.6
aktualisiert wurden, kann einer der folgenden Fehler auftreten.
Beim Aktualisieren der ConfigMap des Clusters kann der Cluster den folgenden Fehler erhalten:
Error from server (InternalError): error when replacing "/tmp/file.yaml":
Internal error occurred: failed calling webhook "config.webhook.istio.networking.internal.knative.dev":
the server rejected our request for an unknown reason
Wenn die Pods aufgrund eines Ausfalls eines Warteschlangenproxys nicht gestartet werden können, kann der Cluster den folgenden Fehler erhalten:
Startup probe failed: flag provided but not defined: -probe-timeout
Zum Beheben dieser Fehler müssen Sie den folgenden Befehl ausführen, um die validatingwebhookconfiguration
-Konfiguration zu entfernen, die in 0.20.0
nicht mehr unterstützt wird:
kubectl delete validatingwebhookconfiguration config.webhook.istio.networking.internal.knative.dev
Nachdem Sie die nicht unterstützte Konfiguration entfernt haben, können Sie mit der Aktualisierung der ConfigMap des Clusters fortfahren.
Fehlende Messwerte nach dem Upgrade auf Cloud Run for Anthos 0.23.0-gke.9
Problem: Die folgenden Messwerte fehlen nach dem Upgrade Ihrer Clusterversion auf 0.23.0-gke.9
: Request count
, Request latencies
und Container instance count
Mögliche Ursache: Metric Collector
ist deaktiviert.
So ermitteln Sie, ob der Metric Collector
die Erfassung von Messwerten verhindert:
Prüfen Sie mit dem folgenden Befehl, ob Ihre Cloud Run for Anthos-Version
0.23.0-gke.9
ist:kubectl get deployment controller -n knative-serving -o jsonpath='{.metadata.labels.serving\.knative\.dev/release}'
Prüfen Sie mit dem folgenden Befehl, ob
Metric Collector
deaktiviert ist:kubectl get cloudrun cloud-run -n cloud-run-system -o jsonpath='{.spec.metricscollector}'
Metric Collector
ist deaktiviert, wenn das Ergebnis nicht{enabled: true}
ist.Führen Sie einen der folgenden Befehle aus, um
Metric Collector
zu aktivieren:Wenn das Ergebnis leer ist, führen Sie Folgendes aus:
kubectl patch cloudrun cloud-run -n cloud-run-system --type='json' -p='[{"op": "test", "path": "/spec", "value": NULL}, {"op": "add", "path": "/spec", "value": {}}]' kubectl patch cloudrun cloud-run -n cloud-run-system --type='json' -p='[{"op": "test", "path": "/spec/metricscollector", "value": NULL}, {"op": "add", "path": "/spec/metricscollector", "value": {}}]' kubectl patch cloudrun cloud-run -n cloud-run-system --type='json' -p='[{"op": "add", "path": "/spec/metricscollector/enabled", "value": true}]'
Wenn das Ergebnis
{enabled: false}
ist, führen Sie folgenden Befehl aus:kubectl patch cloudrun cloud-run -n cloud-run-system --type='json' -p='[{"op": "replace", "path": "/spec/metricscollector/enabled", "value": true}]'
Prüfen Sie mit dem folgenden Befehl, ob
Metric Collector
aktiviert ist:kubectl get cloudrun cloud-run -n cloud-run-system -o jsonpath='{.spec.metricscollector}'