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

Risolvere i problemi

Questa pagina fornisce strategie per la risoluzione dei problemi, oltre a soluzioni per alcuni errori comuni.

Prima di risolvere i problemi di Cloud Run for Anthos, assicurati innanzitutto di poter eseguire l'immagine del container in locale.

Se la tua applicazione non è in esecuzione in locale, dovrai diagnosticare e risolvere i problemi. Utilizza Cloud Logging per eseguire il debug di un progetto di cui hai eseguito il deployment.

Durante la risoluzione dei problemi di Cloud Run for Anthos, consulta le seguenti sezioni per le possibili soluzioni al problema.

Consulta anche la pagina dei problemi noti per i dettagli sui problemi noti di Cloud Run for Anthos e su come risolverli.

Controllo dell'output della riga di comando

Se utilizzi Google Cloud CLI, controlla l'output del comando per verificare se è riuscito o meno. Ad esempio, se il deployment non è stato completato correttamente, dovrebbe essere visualizzato un messaggio di errore che descrive il motivo dell'errore.

Gli errori di deployment sono molto probabilmente dovuti a un manifest configurato in modo errato o a un comando errato. Ad esempio, il seguente output indica che devi configurare la percentuale di traffico del percorso sommando a 100.

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

Controllo dei log per il tuo servizio in corso...

Puoi utilizzare Cloud Logging o la pagina Cloud Run for Anthos in Google Cloud Console per controllare i log delle richieste e quelli dei container. Per i dettagli completi, consulta Log e visualizzazione dei log.

Se utilizzi Cloud Logging, la risorsa su cui è necessario applicare il filtro è Container Kubernetes.

Verifica dello stato del servizio

Esegui il comando seguente per ottenere lo stato di un servizio Cloud Run for Anthos di cui è stato eseguito il deployment:

gcloud run services describe SERVICE

Puoi aggiungere --format yaml(status) o --format json(status) per ottenere lo stato completo, ad esempio:

gcloud run services describe SERVICE --format 'yaml(status)'

Le condizioni indicate in status possono aiutarti a individuare la causa dell'errore. Le condizioni possono includere True, False o Unknown:

Pronto: True indica che il servizio è configurato e pronto a ricevere il traffico.
ConfigurationReady: True indica che la configurazione sottostante è pronta. Per False o "Sconosciuto", dovresti visualizzare lo stato dell'ultima revisione.
RoutesReady: True indica che il route sottostante è pronto. Per False o "Sconosciuto", dovresti visualizzare lo stato del percorso.

Per ulteriori dettagli sulle condizioni di stato, consulta la pagina Segnalazione degli errori Knative.

Verifica dello stato del percorso

Ogni servizio Cloud Run for Anthos gestisce una route che rappresenta lo stato di routing attuale rispetto alle revisioni del servizio.

Puoi verificare lo stato generale del percorso controllando lo stato del servizio:

gcloud run services describe SERVICE --format 'yaml(status)'

La condizione RoutesReady in status fornisce lo stato del percorso.

Puoi diagnosticare ulteriormente lo stato del percorso eseguendo il comando seguente:

kubectl get route SERVICE -o yaml

Le condizioni in status indicano il motivo di un errore. Vale a dire:

Pronto indica se il servizio è configurato e ha backend disponibili. Se questo è true, il percorso è configurato correttamente.
AllTrafficAssigned indica se il servizio è configurato correttamente e ha backend disponibili. Se status di questa condizione non è True:
- Prova a controllare se la suddivisione del traffico tra le revisioni del tuo servizio raggiunge il 100%:
```
gcloud run services describe SERVICE
```
  In caso contrario, modifica la suddivisione del traffico utilizzando il comando gcloud run services update-traffic.
- Prova a controllare lo stato della revisione per la revisione che riceve il traffico.
IngressReady indica se la risorsa Ingress è pronta. Se il valore status di questa condizione non è True, prova a controllare lo stato del traffico in entrata.
CertificateProvisioned indica se è stato eseguito il provisioning dei certificati Knative. Se il valore di status per questa condizione non è True, prova a risolvere i problemi relativi alla crittografia TLS gestita.

Per ulteriori dettagli sulle condizioni di stato, consulta Condizioni di errore native e report.

Controllo dello stato di Ingress

Cloud Run for Anthos utilizza un servizio Kubernetes di bilanciatore del carico, chiamato istio-ingress, responsabile della gestione del traffico in entrata dall'esterno del cluster.

Per ottenere l'indirizzo IP esterno della tua risorsa Ingress, utilizza

kubectl get svc istio-ingress -n gke-system

Se EXTERNAL-IP è pending, vedi EXTERNAL-IP è pending per un periodo prolungato di seguito.

Verifica dello stato della revisione

Per ottenere l'ultima revisione del servizio Cloud Run for Anthos, esegui questo comando:

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

Esegui il comando seguente per ottenere lo stato di una revisione specifica di Cloud Run for Anthos:

gcloud run revisions describe REVISION

Puoi aggiungere --format yaml(status) o --format json(status) per ottenere lo stato completo:

gcloud run revisions describe REVISION --format yaml(status)

Le condizioni in status forniscono i motivi per un errore. Vale a dire:

Pronto indica se le risorse di runtime sono pronte. Se è true, la revisione è configurata correttamente.
ResourcesAvailable indica se è stato eseguito il provisioning delle risorse Kubernetes sottostanti. Se il valore status di questa condizione non è True, prova a controllare lo stato del pod.
ContainerHealthy indica se il controllo di idoneità per la revisione è stato completato. Se il valore status di questa condizione non è True, prova a controllare lo stato del pod.
Attivo indica se la revisione riceve traffico.

Se una di queste condizioni status non è True, prova a controllare lo stato del pod.

Verifica dello stato del pod

Per ottenere i pod per tutti i tuoi deployment:

kubectl get pods

Questo dovrebbe elencare tutti i pod con un breve stato. Ad esempio:

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

Scegline uno e usa il comando seguente per visualizzare informazioni dettagliate sull'elemento status. Alcuni campi utili sono conditions e containerStatuses:

kubectl get pod POD-NAME -o yaml

L'IP EXTERNAL è `<pending>` da molto tempo

A volte potresti non ricevere un indirizzo IP esterno subito dopo aver creato un cluster, ma vedere invece l'IP esterno come pending. Ad esempio, potresti vedere questo comando richiamando il comando:

Per ottenere l'IP esterno per il gateway in entrata Istio:

kubectl get svc istio-ingress -n gke-system

in cui l'output risultante ha questo aspetto:

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

EXTERNAL-IP per il bilanciatore del carico è l'indirizzo IP che devi utilizzare.

Ciò può significare che hai esaurito la quota di indirizzi IP esterni in Google Cloud. Puoi verificare la possibile causa richiamando:

kubectl describe svc istio-ingress -n gke-system

Questo restituisce un output simile al seguente:

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

Se l'output contiene un'indicazione che la quota IN_USE_ADDRESSES è stata superata, puoi richiedere una quota aggiuntiva accedendo alla pagina IAM e amministrazione nella console Google Cloud per richiedere una quota aggiuntiva.

Il gateway continuerà a riprovare fino all'assegnazione di un indirizzo IP esterno. L'operazione potrebbe richiedere alcuni minuti.

Risolvere i problemi relativi alla crittografia TLS gestita

Segui i passaggi di risoluzione dei problemi elencati di seguito per risolvere i problemi generali relativi alla funzionalità Certificati TLS gestiti.

Controllare lo stato di una mappatura di dominio specifica

Per controllare lo stato di una mappatura di dominio specifica:

Esegui il comando:
```
gcloud run domain-mappings describe --domain DOMAIN --namespace NAMESPACE
```
Sostituisci
- DOMAIN con il nome del dominio che stai utilizzando.
- NAMESPACE con lo spazio dei nomi utilizzato per la mappatura del dominio.
Nei risultati yaml di questo comando, esamina la condizione del campo CertificateProvisioned per determinare la natura dell'errore.
Se viene mostrato un errore, dovrebbe corrispondere a uno degli errori nelle tabelle di seguito. Per risolvere il problema, segui i suggerimenti contenuti nelle tabelle.

Errori di configurazione utente

Codice di errore	Messaggio dettagliato	Istruzioni per la risoluzione dei problemi
Errore DNS	Il record DNS non è configurato correttamente. Devi mappare il dominio [XXX] a IP XX,XX.XX.XX	Segui le istruzioni fornite per configurare correttamente il record DNS.
Limitazione frequenza superata	acme: urn:ietf:params:acme:error:rateRestricted: Errore durante la creazione del nuovo ordine : numero eccessivo di certificati già emessi per un insieme esatto di domini: test.example.com: Vedi https://letsencrypt.org/docs/rate-limits/	Contatta Let's Encrypt per aumentare la quota di certificati per l'host in questione.
NomeDominioDominioNon valido	Il nome di mappatura di dominio %s non può essere uguale all'host dell'URL di route %s.	Il nome di DomainMapping non può coincidere esattamente con l'host del Route a cui è mappato. Utilizza un dominio diverso per il nome di DomainMapping.
Errore di pubblicazione verifica	Il sistema non è riuscito a gestire la richiesta HTTP01.	Questo errore può verificarsi se il servizio `istio-ingress` non è in grado di gestire la richiesta di Let's Encrypt per convalidare la proprietà del dominio.	Assicurati che il servizio `istio-ingress` sia accessibile dalla rete Internet pubblica senza utilizzare Virtual Private Cloud. Assicurati che il servizio `istio-ingress` accetti le richieste dall'URL `http://DOMAIN/.well-known/acme-challenge/...` in cui `DOMAIN` è il dominio da convalidare.

Errori di sistema

Codice di errore	Messaggio dettagliato	Istruzioni per la risoluzione dei problemi
Errore ordine Errore di autenticazione Errore di verifica		Questi tre tipi di errori si verificano se la verifica della proprietà del dominio da parte di Let's Encrypt non va a buon fine. In genere questi errori sono temporanei e vengono ritentati da Cloud Run for Anthos. Il ritardo del nuovo tentativo è esponenziale tra minimo 8 secondi e massimo 8 ore. Se vuoi riprovare manualmente l'errore, puoi eliminare manualmente l'ordine non riuscito. `kubectl delete order DOMAIN -n NAMESPACE`
APIAPI non riuscita		Questo tipo di errore si verifica quando Cloud Run for Anthos non chiama Let's Encrypt. In genere si tratta di un errore transitorio e si proverà nuovamente a eseguire Cloud Run for Anthos. Se vuoi riprovare manualmente l'errore, elimina manualmente l'ordine non riuscito. `kubectl delete order DOMAIN -n NAMESPACE`
Errore sconosciuto		Questo errore indica un errore di sistema sconosciuto, che deve verificarsi molto raramente nel cluster GKE. Se visualizzi questo messaggio, contatta l'assistenza Cloud per ricevere aiuto per il debug.

Verifica lo stato dell'ordine

Lo stato dell'ordine registra il processo di interazione con Let's Encrypt e pertanto può essere utilizzato per eseguire il debug dei problemi relativi a Let's Encrypt. Se necessario, controlla lo stato dell'ordine eseguendo questo comando:

kubectl get order DOMAIN -n NAMESPACE -oyaml

Sostituisci

DOMAIN con il nome del dominio che stai utilizzando.
NAMESPACE con lo spazio dei nomi utilizzato per la mappatura del dominio.

I risultati conterranno i certificati emessi e altre informazioni se l'ordine è stato eseguito correttamente.

Supera la quota della crittografia

Controlla lo stato di DomainMapping. Se superi la quota di Let's Encrypt, nel DomainMapping verrà visualizzato un messaggio di errore simile al seguente:

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/'

Fai riferimento alla documentazione relativa alla crittografia dei limiti di frequenza per aumentare la quota di certificati.

Timeout ordine

Se un oggetto Order non riesce ancora a ricevere i certificati, si verifica il timeout dopo 20 minuti.

Verifica lo stato della mappatura del dominio. In caso di timeout, cerca un messaggio di errore simile al seguente nell'output dello stato:
```
order (test.example.com) timed out (20.0 minutes)
```
Una causa comune del problema di timeout è che il tuo record DNS non è configurato correttamente per mappare il dominio che stai utilizzando all'indirizzo IP del servizio istio-ingress in gke-system. Esegui questo comando per controllare il record DNS:
```
host DOMAIN
```
Esegui questo comando per controllare l'indirizzo IP esterno del servizio istio-ingress in gke-system:
```
kubectl get svc istio-ingress -n gke-system
```
Se l'indirizzo IP esterno del tuo dominio non corrisponde all'indirizzo IP in entrata, riconfigura il record DNS per mapparlo all'indirizzo IP corretto.
Una volta che il record DNS (aggiornato) diventa effettivo, esegui il comando seguente per eliminare l'oggetto Order al fine di riattivare il processo di richiesta di un certificato TLS:
```
kubectl delete order DOMAIN -n NAMESPACE
```
Sostituisci
- DOMAIN con il nome del dominio che stai utilizzando.
- NAMESPACE con lo spazio dei nomi utilizzato.

Errori di autorizzazione

Gli errori di autorizzazione possono verificarsi quando un record DNS non viene propagato a livello globale in tempo. Di conseguenza, Let's Encrypt non riesce a verificare la proprietà del dominio.

Controlla lo stato dell'ordine. Il link di autorizzazione si trova sotto il campo acmeAuthorizations dello stato. L'URL dovrebbe essere simile al seguente:
```
https://acme-v02.api.letsencrypt.org/acme/authz-v3/1717011827
```
Apri il link. Se vedi un messaggio simile a:
```
urn:ietf:params:acme:error:dns
```
il problema è dovuto a una propagazione del DNS incompleta.
Risoluzione dell'errore di propagazione del DNS:
1. Ottieni l'IP esterno del servizio istio-ingress in gke-system eseguendo il comando seguente:
```
kubectl get svc istio-ingress -n gke-system
```
2. Controlla il record DNS per il dominio eseguendo questo comando:
```
host DOMAIN
```
  Se l'indirizzo IP del record DNS non corrisponde all'IP esterno del servizio istio-ingress in gke-system, configura il record DNS per mappare il dominio dell'utente all'IP esterno.
3. Una volta che il record DNS (aggiornato) diventa effettivo, esegui il comando seguente per eliminare l'oggetto Order e riattivare il processo di richiesta di un certificato TLS:
```
kubectl delete order DOMAIN -n NAMESPACE
```
Sostituisci
- DOMAIN con il nome del dominio che stai utilizzando.
- NAMESPACE con lo spazio dei nomi utilizzato per la mappatura del dominio.

Deployment in errore del cluster privato: errore di chiamata webhook non riuscita

Il firewall potrebbe non essere configurato correttamente se il deployment in un cluster privato non va a buon fine con il messaggio:

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)

Per informazioni sulle modifiche firewall necessarie per supportare il deployment in un cluster privato, consulta la pagina Abilitare i deployment su un cluster privato.

Stato del report Servizi di IngressNotConfigured

Se IngressNotConfigured viene visualizzato nello stato del servizio, potrebbe essere necessario riavviare il deployment istio-pilot nello spazio dei nomi gke-system. Questo errore, che è stato osservato più frequentemente su Kubernetes 1.14, può verificarsi se i servizi vengono creati prima che istio_pilot sia pronto per iniziare il lavoro di riconciliazione di VirtualServices e di push della configurazione del metodo di invio ai gateway in entrata.

Per risolvere questo problema, fai lo scale in del deployment, quindi ripeti il deployment utilizzando i comandi simili ai seguenti:

kubectl scale deployment istio-pilot -n gke-system --replicas=0
kubectl scale deployment istio-pilot -n gke-system --replicas=1

Metriche relative al numero e alla latenza delle richieste mancanti

Il tuo servizio potrebbe non registrare il conteggio delle richieste di revisione e le metriche di latenza delle richieste se hai abilitato Workload Identity e non hai concesso determinate autorizzazioni all'account di servizio utilizzato dal servizio.

Per risolvere il problema, segui i passaggi nella sezione Abilitare metriche su un cluster con Workload Identity.

Utilizzo di WebSocket con domini personalizzati

Per impostazione predefinita, i WebSocket sono disattivati per le mappature dei domini personalizzati.

Per abilitare WebSocket per i domini personalizzati, esegui questo comando per creare un oggetto Istio EnvoyFilter con allow_connect: true:

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