Bekannte Probleme in Cloud Run for Anthos

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:

  1. Starten Sie den Webhook-Pod neu, um MutatingWebhookConfiguration neu zu erstellen:

    kubectl delete pod -n knative-serving -lapp=webhook
kubectl get mutatingwebhookconfiguration --watch

  2. Starten Sie die Controller neu:

    kubectl delete pod -n gke-system -listio=pilot
kubectl delete pod -n knative-serving -lapp=controller

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

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

  1. Führen Sie den folgenden Befehl aus, um alle DomainMappings aufzulisten:

    kubectl get domainmapping --all-namespaces

  2. 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:

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:

  1. 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}'

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

  3. 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}]'

  4. 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}'