Risoluzione dei problemi

Questa pagina fornisce strategie di risoluzione dei problemi e soluzioni ad alcuni errori comuni.

Quando risolvi i problemi relativi a Knative Serving, verifica innanzitutto di poter eseguire l'immagine container localmente.

Se l'applicazione non viene eseguita in locale, dovrai diagnosticare e risolvere il problema. Per eseguire il debug di un progetto di cui è stato eseguito il deployment, devi utilizzare Cloud Logging.

Quando risolvi i problemi di Knative Serving, consulta le seguenti sezioni per possibili soluzioni al problema.

Controllo dell'output della riga di comando

Se utilizzi Google Cloud CLI, controlla l'output del comando per verificare se l'operazione è riuscita. Ad esempio, se il deployment è terminato senza esito positivo, dovrebbe essere presente un messaggio di errore che descrive il motivo del problema.

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 della route in modo che la somma sia 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

Controllare i log del servizio

Puoi utilizzare Cloud Logging o la pagina Knative Serving nella consoleGoogle Cloud per controllare i log delle richieste e i log dei container. Per tutti i dettagli, leggi Registrazione e visualizzazione dei log.

Se utilizzi Cloud Logging, la risorsa su cui devi filtrare è Contenitore Kubernetes.

Controllo dello stato del servizio in corso…

Esegui questo comando per ottenere lo stato di un servizio Knative Serving di cui è stato eseguito il deployment:

gcloud run services describe SERVICE

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

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

Le condizioni 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 traffico.
• ConfigurationReady: True indica che la configurazione sottostante è pronta. Per False o Unknown, devi visualizzare lo stato dell'ultima revisione.
• RoutesReady: True indica che la route sottostante è pronta. Per False o Unknown, devi visualizzare lo stato dell'itinerario.

Per ulteriori dettagli sulle condizioni di stato, consulta Knative Error Signaling.

Controllo dello stato dell'itinerario

Ogni servizio Knative Serving gestisce una Route che rappresenta lo stato di routing attuale rispetto alle revisioni del servizio.

Puoi controllare lo stato generale dell'itinerario esaminando lo stato del servizio:

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

La condizione RoutesReady in status fornisce lo stato della route.

Puoi diagnosticare ulteriormente lo stato della route eseguendo il seguente comando:

kubectl get route SERVICE -o yaml

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

• Pronto indica se il servizio è configurato e dispone di backend disponibili. Se è true, la route è configurata correttamente.

• AllTrafficAssigned indica se il servizio è configurato correttamente e dispone di backend disponibili. Se il status di questa condizione non è True:

  • Prova a controllare se la suddivisione del traffico tra le revisioni del servizio dà come risultato 100%:

    gcloud run services describe SERVICE

    In caso contrario, regola la distribuzione del traffico utilizzando il comando gcloud run services update-traffic.

  • Prova a controllare lo stato della revisione per le revisioni che ricevono traffico.

• IngressReady indica se l'ingresso è pronto. Se il status di questa condizione non è True, prova a controllare lo stato dell'ingresso.

• CertificateProvisioned indica se i certificati Knative sono stati di cui è stato eseguito il provisioning. Se status di questa condizione non è True, prova a risolvere i problemi relativi a TLS gestito.

Per ulteriori dettagli sulle condizioni di stato, consulta Knative Error Conditions and Reporting.

Controllo dello stato di Ingress

Knative Serving utilizza un servizio di bilanciamento del carico chiamato istio-ingressgateway, che è responsabile della gestione del traffico in entrata dall'esterno del cluster.

Per ottenere l'IP esterno del bilanciatore del carico, esegui questo comando:

kubectl get svc istio-ingressgateway -n ASM-INGRESS-NAMESPACE

Sostituisci ASM-INGRESS-NAMESPACE con lo spazio dei nomi in cui si trova l'ingresso Cloud Service Mesh. Specifica istio-system se hai installato Cloud Service Mesh utilizzando la configurazione predefinita.

L'output risultante è simile al seguente:

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

dove il valore EXTERNAL-IP è l'indirizzo IP esterno del bilanciatore del carico.

Se EXTERNAL-IP è pending, consulta la sezione EXTERNAL-IP è pending da molto tempo di seguito.

Controllo dello stato della revisione

Per ottenere l'ultima revisione del servizio Knative, esegui questo comando:

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

Esegui questo comando per ottenere lo stato di una revisione di Knative Serving specifica:

gcloud run revisions describe REVISION

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

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

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

• Pronto indica se le risorse di runtime sono pronte. Se si tratta di true, la revisione è configurata correttamente.
• ResourcesAvailable indica se è stato eseguito il provisioning delle risorse Kubernetes sottostanti. Se status di questa condizione non è True, prova a controllare lo stato del pod.
• ContainerHealthy indica se il controllo di idoneità della revisione è stato completato. Se 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.

Controllo dello stato del pod

Per ottenere i pod per tutti i tuoi deployment:

kubectl get pods

Dovrebbe essere visualizzato l'elenco di 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

Scegli una delle opzioni e utilizza il seguente comando per visualizzare informazioni dettagliate per il relativo status. Alcuni campi utili sono conditions e containerStatuses:

kubectl get pod POD-NAME -o yaml

EXTERNAL-IP è <pending> da molto tempo

A volte, potresti non ottenere un indirizzo IP esterno immediatamente dopo aver creato un cluster, ma visualizzare l'IP esterno come pending. Ad esempio, puoi visualizzarlo richiamando il comando:

Per ottenere l'IP esterno del bilanciatore del carico, esegui questo comando:

kubectl get svc istio-ingressgateway -n ASM-INGRESS-NAMESPACE

Sostituisci ASM-INGRESS-NAMESPACE con lo spazio dei nomi in cui si trova l'ingresso Cloud Service Mesh. Specifica istio-system se hai installato Cloud Service Mesh utilizzando la configurazione predefinita.

L'output risultante è simile al seguente:

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

dove il valore EXTERNAL-IP è l'indirizzo IP esterno del bilanciatore del carico.

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

kubectl describe svc istio-ingressgateway -n INGRESS_NAMESPACE

dove INGRESS_NAMESPACE è lo spazio dei nomi dell'ingresso ASM, che per impostazione predefinita è `istio-system`. L'output è simile al seguente:

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

Se l'output contiene un'indicazione del superamento della quota IN_USE_ADDRESSES, 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 finché non viene assegnato un indirizzo IP esterno. L'operazione potrebbe richiedere alcuni minuti.

Risoluzione dei problemi relativi ai domini personalizzati e a TLS gestito

Utilizza i passaggi per la risoluzione dei problemi elencati di seguito per risolvere i problemi generali relativi ai domini personalizzati e alla funzionalità certificati TLS gestiti.

Domini personalizzati per reti private e interne

Se hai mappato un dominio personalizzato al tuo cluster o ai tuoi servizi Knative Serving all'interno di una rete privata e interna, devi disattivare i certificati TLS gestiti, altrimenti la configurazione del dominio non raggiungerà lo stato ready. Per impostazione predefinita, il bilanciatore del carico interno non è in grado di comunicare esternamente con l'autorità di certificazione.

Controllare lo stato di una mappatura di dominio specifica

Per controllare lo stato di una mappatura di dominio specifica:

1. 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 che utilizzi per la mappatura del dominio.

2. Nei risultati yaml di questo comando, esamina la condizione del campo CertificateProvisioned per determinare la natura dell'errore.

3. Se viene visualizzato un errore, deve corrispondere a uno degli errori nelle tabelle riportate di seguito. Segui i suggerimenti riportati nelle tabelle per risolvere il problema.

Errori di configurazione utente

Codice di errore	Dettagli
DNSErrored	Messaggio: Il record DNS non è configurato correttamente. È necessario mappare il dominio [XXX] all'IP XX.XX.XX.XX Segui le istruzioni fornite per configurare correttamente il record DNS.
RateLimitExceeded	Messaggio: acme: urn:ietf:params:acme:error:rateLimited: Error creating new order :: too many certificates already issued for exact set of domains: test.your-domain.com: see https://letsencrypt.org/docs/rate-limits/ La quota di Let's Encrypt è stata superata. Devi aumentare la quota del certificato Let's Encrypt per l'host.
InvalidDomainMappingName	Messaggio: Il nome DomainMapping %s non può essere uguale all'host URL di Route %s. Il nome DomainMapping non può essere esattamente uguale all'host della Route a cui esegue il mapping. Utilizza un dominio diverso per il nome DomainMapping.
ChallengeServingErrored	Messaggio: Il sistema non è riuscito a gestire la richiesta HTTP01. Questo errore può verificarsi se il servizio istio-ingressgateway non è in grado di gestire la richiesta di Let's Encrypt per convalidare la proprietà del dominio. Assicurati che il servizio istio-ingressgateway sia accessibile da internet pubblico senza utilizzare Virtual Private Cloud. Assicurati che il servizio istio-ingressgateway accetti le richieste dall'URL http://DOMAIN/.well-known/acme-challenge/... dove DOMAIN è il dominio da convalidare.

Errori di sistema

Codice di errore	Dettagli
OrderErrored AuthzErrored ChallengeErrored	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. Questi errori sono in genere temporanei e verranno riprovati da Knative Serving. Il ritardo tra i tentativi è esponenziale, con un minimo di 8 secondi e un massimo di 8 ore. Se vuoi riprovare manualmente a correggere l'errore, puoi eliminare manualmente l'ordine non riuscito. kubectl delete order DOMAIN -n NAMESPACE
ACMEAPIFailed	Questo tipo di errore si verifica quando Knative Serving non riesce a chiamare Let's Encrypt. Di solito si tratta di un errore temporaneo e verrà riprovato da Knative Serving. Se vuoi riprovare manualmente a risolvere l'errore, elimina manualmente l'ordine non riuscito. kubectl delete order DOMAIN -n NAMESPACE
UnknownErrored	Questo errore indica un errore di sistema sconosciuto, che dovrebbe verificarsi molto raramente nel cluster GKE. Se visualizzi questo messaggio, contatta l'assistenza Cloud per ricevere aiuto per il debug.

Controllare lo stato dell'ordine

Lo stato dell'ordine registra la procedura 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 che utilizzi per la mappatura del dominio.

Se l'ordine è andato a buon fine, i risultati conterranno i certificati emessi e altre informazioni.

Timeout ordine

Un oggetto Order andrà in timeout dopo 20 minuti se non riesce ancora a ottenere i certificati.

1. Controlla lo stato della mappatura di dominio. Per un timeout, cerca un messaggio di errore come questo nell'output di stato:

   order (test.your-domain.com) timed out (20.0 minutes)

2. Una causa comune del problema di timeout è che il record DNS non è configurato correttamente per mappare il dominio che stai utilizzando all'indirizzo IP del servizio di ingresso. Esegui questo comando per controllare il record DNS:

   host DOMAIN

3. Controlla l'indirizzo IP esterno del bilanciatore del carico in entrata:

   Per ottenere l'IP esterno del bilanciatore del carico, esegui questo comando:

   kubectl get svc istio-ingressgateway -n ASM-INGRESS-NAMESPACE

   Sostituisci ASM-INGRESS-NAMESPACE con lo spazio dei nomi in cui si trova l'ingresso Cloud Service Mesh. Specifica istio-system se hai installato Cloud Service Mesh utilizzando la configurazione predefinita.

   L'output risultante è simile al seguente:

   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

   dove il valore EXTERNAL-IP è l'indirizzo IP esterno del bilanciatore del carico.

   Se l'indirizzo IP esterno del tuo dominio non corrisponde all'indirizzo IP in entrata, riconfigura il record DNS in modo che venga mappato all'indirizzo IP corretto.

4. Una volta che il record DNS (aggiornato) diventa effettivo, esegui questo comando per eliminare l'oggetto Order e riavviare la procedura 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 che utilizzi.

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.

1. Controlla lo stato dell'ordine. Trova il link di autorizzazione nel campo acmeAuthorizations dello stato. L'URL dovrebbe essere simile a questo:

   https://acme-v02.api.letsencrypt.org/acme/authz-v3/1717011827

2. Apri il link. Se viene visualizzato un messaggio simile a:

   urn:ietf:params:acme:error:dns

   allora il problema è dovuto alla propagazione DNS incompleta.

3. Per risolvere l'errore di propagazione DNS:

   1. Controlla l'indirizzo IP esterno del bilanciatore del carico in entrata:

      Per ottenere l'IP esterno del bilanciatore del carico, esegui questo comando:

      kubectl get svc istio-ingressgateway -n ASM-INGRESS-NAMESPACE

      Sostituisci ASM-INGRESS-NAMESPACE con lo spazio dei nomi in cui si trova l'ingresso Cloud Service Mesh. Specifica istio-system se hai installato Cloud Service Mesh utilizzando la configurazione predefinita.

      L'output risultante è simile al seguente:

      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

      dove il valore EXTERNAL-IP è l'indirizzo IP esterno del bilanciatore del carico.

   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 bilanciatore del carico in entrata, configura il record DNS in modo da mappare il dominio dell'utente all'IP esterno.

   3. Dopo che il record DNS (aggiornato) diventa effettivo, esegui questo comando per eliminare l'oggetto Ordine e riattivare la procedura 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 che utilizzi per la mappatura del dominio.

Deployment nel cluster privato non riuscito: errore di chiamata del webhook

Il firewall potrebbe non essere configurato correttamente se il deployment in un cluster privato non va a buon fine e viene visualizzato 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 al firewall necessarie per supportare il deployment in un cluster privato, consulta Attivazione dei deployment in un cluster privato.

I report sui servizi mostrano lo stato IngressNotConfigured

Se IngressNotConfigured viene visualizzato nello stato del servizio, potrebbe essere necessario riavviare il deployment di istiod nello spazio dei nomi istio-system se utilizzi il piano di controllo in-cluster di Cloud Service Mesh. Questo errore, che è stato osservato più frequentemente su kubernetes 1.14, può verificarsi se i servizi vengono creati prima che istiod sia pronto per iniziare il suo lavoro di riconciliazione di VirtualServices e di push della configurazione di Envoy ai gateway in entrata.

Per risolvere il problema, esegui lo scale in e poi lo scale out del deployment utilizzando comandi simili ai seguenti:

kubectl scale deployment istiod -n istio-system --replicas=0
kubectl scale deployment istiod -n istio-system --replicas=1

Metriche mancanti per il conteggio delle richieste e la latenza delle richieste

Il tuo servizio potrebbe non segnalare il conteggio delle richieste di revisione e le metriche di latenza delle richieste se hai abilitato Workload Identity Federation for GKE e non hai concesso determinate autorizzazioni aaccount di serviziont utilizzato dal tuo servizio.

Puoi risolvere il problema seguendo i passaggi descritti nella sezione Abilitazione delle metriche su un cluster con la federazione delle identità per i carichi di lavoro per GKE.