Questa è la versione Archiviata della documentazione. Il periodo di prova gratuito è terminato il 30 settembre 2021.

Per informazioni dettagliate sull'installazione di Cloud Run for Anthos come componente del parco Anthos con Anthos Service Mesh, consulta la documentazione sulla versione GA.

Versioni disponibili

Più recenti
Archiviare

Problemi noti di Cloud Run for Anthos

Questa pagina elenca i problemi noti di Cloud Run for Anthos. Per vulnerabilità note relative alla sicurezza, consulta le best practice per la sicurezza.

Puoi anche controllare se esistono problemi esistenti o aprirne di nuovi negli strumenti di monitoraggio pubblici dei problemi.

Consulta anche la pagina relativa alla risoluzione dei problemi per le strategie di risoluzione dei problemi e per le soluzioni di alcuni errori comuni.

Servizi bloccati in `RevisionMissing` perché mancano `MutatingWebhookConfiguration`

La creazione di un nuovo servizio o di una nuova revisione del servizio potrebbe bloccarsi nello stato "RevisionMissing" a causa di una configurazione webhook mancante. Puoi verificarlo utilizzando il comando

kubectl get mutatingwebhookconfiguration webhook.serving.knative.dev

che restituisce

kmutatingwebhookconfigurations.admissionregistration.k8s.io "webhook.serving.knative.dev" not found`

Soluzione temporanea

Finché non sarà risolto in una versione futura, puoi procedere come segue per risolvere questo problema:

Riavvia il pod webhook per ricreare l'elemento MutatingWebhookConfiguration:

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

Riavvia i controller:

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

Esegui il deployment di una nuova revisione per ogni servizio che presenta il problema RevisionMissing:
```
gcloud run services update SERVICE --update-labels client.knative.dev/nonce=""
```
sostituendo SERVICE con il nome del servizio.
Se riscontri lo stesso problema durante il deployment di nuove revisioni del servizio, ripeti i passaggi precedenti.

Cluster di zona

Quando utilizzi un cluster di zona con Cloud Run for Anthos, l'accesso al piano di controllo non è disponibile durante la manutenzione del cluster.

Durante questo periodo, Cloud Run for Anthos potrebbe non funzionare come previsto. Servizi di cui è stato eseguito il deployment in quel cluster

Non vengono mostrati nella console Cloud o tramite gcloud CLI
Impossibile eliminare o aggiornare
Non scala automaticamente le istanze, ma le istanze esistenti continueranno a gestire le nuove richieste

Per evitare questi problemi, puoi utilizzare un cluster a livello di regione, che garantisce un piano di controllo ad alta disponibilità.

Il limite di memoria predefinito non viene applicato tramite la riga di comando

Se utilizzi la riga di comando per eseguire il deployment dei tuoi servizi, devi includere il flag --memory per impostare un limite di memoria per quel servizio. L'esclusione del flag --memory consente a un servizio di consumare fino alla quantità totale di memoria disponibile sul nodo in cui è in esecuzione il pod, con possibili effetti collaterali imprevisti.

Quando esegui il deployment tramite la console Google Cloud, viene utilizzato il valore predefinito 256M, a meno che non venga specificato un valore diverso.

Per evitare di definire limiti predefiniti per ogni servizio, puoi scegliere di definire un limite di memoria predefinito per lo spazio dei nomi in cui esegui il deployment dei servizi. Per ulteriori informazioni, consulta la pagina sulla configurazione dei limiti di memoria predefiniti nella documentazione di Kubernetes.

Il limite di CPU predefinito non è abilitato

Quando si esegue il deployment utilizzando la riga di comando o console, la quantità di CPU che un servizio può utilizzare non è definita. Ciò consente al servizio di consumare tutta la CPU disponibile nel nodo in cui è in esecuzione, il che potrebbe avere effetti collaterali imprevisti.

Per risolvere il problema, puoi definire un limite di CPU predefinito per lo spazio dei nomi in cui esegui il deployment dei servizi con Cloud Run for Anthos. Per ulteriori informazioni, consulta la sezione sulla configurazione dei limiti di CPU predefiniti nella documentazione di Kubernetes.

Nota: per impostazione predefinita, i servizi di cui è stato eseguito il deployment con la richiesta di Cloud Run for Anthos 400m CPU, vengono utilizzati per pianificare le istanze di un servizio sui nodi del cluster.

I contenuti dei punti di lettura/scrittura nel container sono sempre vuoti

Se hai un container, crea in /var/log file o cartelle, ad esempio /var/log/nginx, quando esegui il container in Cloud Run for Anthos, quei file o cartelle non saranno visibili perché su /var/log è stato montato un volume di lettura/scrittura vuoto, che nasconde i contenuti del container sottostante.

Se deve scrivere in una sottodirectory di /var/log, prima di scriverla deve verificare che la cartella esista in fase di esecuzione. Non può presumere l'esistenza della cartella dall'immagine container.

Soluzione alternativa

Se hai eseguito l'upgrade del cluster alla versione 1.17 di GKE e riscontri problemi con il deployment del servizio, devi eliminare il servizio virtuale generato dal DomainMapping poiché non è più compatibile con il nuovo controller. Dopo l'eliminazione, il controller ricrea un VirtualService compatibile e risolve i problemi di deployment del servizio.

Esegui i comandi seguenti per eliminare VirtualService, dove il nome di VirtualService è lo stesso di DomainMappings. Ad esempio: foo.example.com

Esegui il comando seguente per elencare tutti i domini di mappatura dei domini:
```
kubectl get domainmapping --all-namespaces
```

Esegui questo comando per eliminare il servizio virtuale specificato:

kubectl delete vs your-domain-mapping-name -n your-domain-mapping-namespace

Deployment di immagini container private in Artifact Registry

Esiste un problema di deployment noto causato da un errore di autenticazione tra Cloud Run for Anthos e Artifact Registry quando viene eseguito il deployment delle immagini container private. Per evitare problemi durante il deployment delle immagini private in Artifact Registry, puoi:

Utilizza il digest di immagini delle immagini container private per eseguire il deployment di un servizio.
Crea e utilizza un imagePullSecret. L'utilizzo di imagePullSecret ti consente di utilizzare il tag immagine delle immagini container private. Per maggiori dettagli, consulta Deployment di immagini container private da altri registry di container.

Errori di configurazione sui cluster di cui è stato eseguito l'upgrade alla versione `0.20.0-gke.6`

I cluster di cui è stato eseguito l'upgrade alla versione 0.20.0-gke.6 possono ricevere uno dei seguenti errori.

Quando aggiorni la configurazione di cluster, il cluster può ricevere il seguente errore:

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

Se i pod non si avviano a causa di un errore di proxy in coda, il cluster può ricevere il seguente errore:

Startup probe failed: flag provided but not defined: -probe-timeout

Per risolvere questi errori, devi eseguire il comando seguente per rimuovere la configurazione validatingwebhookconfiguration che non è più supportata in 0.20.0:

kubectl delete validatingwebhookconfiguration config.webhook.istio.networking.internal.knative.dev

Dopo aver rimosso la configurazione non supportata, puoi procedere con l'aggiornamento della configurazione del cluster.

Metriche mancanti dopo l'upgrade a Cloud Run for Anthos 0.23.0-gke.9

Problema: mancano le seguenti metriche dopo l'upgrade della versione del cluster a 0.23.0-gke.9: Request count, Request latencies e Container instance count

Possibile causa: Metric Collector è disabilitato.

Per determinare se Metric Collector impedisce la raccolta delle metriche:

Esegui il comando seguente per assicurarti che la tua versione di Cloud Run for Anthos sia 0.23.0-gke.9:

kubectl get deployment controller -n knative-serving -o jsonpath='{.metadata.labels.serving\.knative\.dev/release}'

Controlla se Metric Collector è disattivato eseguendo questo comando:
```
kubectl get cloudrun cloud-run -n cloud-run-system -o jsonpath='{.spec.metricscollector}'
```
Il Metric Collector è disattivato se il risultato non è {enabled: true}.

Per attivare Metric Collector, esegui uno dei seguenti comandi:

Se il risultato è vuoto, esegui:

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

Se il risultato è {enabled: false}, esegui:

kubectl patch cloudrun cloud-run -n cloud-run-system --type='json' -p='[{"op": "replace", "path": "/spec/metricscollector/enabled", "value": true}]'

Verifica che Metric Collector sia abilitato eseguendo questo comando:

kubectl get cloudrun cloud-run -n cloud-run-system -o jsonpath='{.spec.metricscollector}'