Risoluzione dei problemi

Questa pagina fornisce strategie per la risoluzione dei problemi e soluzioni per alcuni e gli errori più comuni.

Quando risolvi i problemi di pubblicazione di Knative, verifica innanzitutto di poter eseguire l'immagine del contenitore localmente.

Se la tua applicazione non viene eseguita in locale, dovrai diagnosticare e risolvere il problema. Dovresti usare Cloud Logging per il debug di un progetto di cui è stato eseguito il deployment.

Per la risoluzione dei problemi di pubblicazione di Knative, consulta le seguenti sezioni per trovare possibili soluzioni al problema.

Controllo dell'output della riga di comando

Se utilizzi Google Cloud CLI, controlla l'output del comando per verificare se è andato a buon fine o meno. Ad esempio, se il deployment è stato terminato senza successo, dovrebbe essere visualizzato un messaggio che descrive il motivo dell'errore.

I problemi di deployment sono probabilmente dovuti a un manifest configurato in modo errato o a un comando errato. Ad esempio, l'output seguente indica che è necessario e configurare la percentuale di traffico della route in modo che corrisponda 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 servizio in corso...

Puoi utilizzare Cloud Logging o la pagina Knative serving nella Console Google Cloud per controllare i log delle richieste e dei container. Per informazioni dettagliate, consulta Generare e visualizzare i log.

Se utilizzi Cloud Logging, la risorsa in base alla quale filtrare i dati è Container Kubernetes.

Controllo dello stato del servizio

Esegui il seguente comando per ottenere lo stato di un servizio di pubblicazione Knative 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:

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

Controllo dello stato del percorso

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

Puoi controllare 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 della route.

Per ulteriori informazioni sullo stato della route, esegui il seguente comando:

kubectl get route SERVICE -o yaml

Le condizioni in status forniscono il motivo dell'errore. Vale a dire:

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

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

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

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

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

Controllo dello stato di Ingress

Knative serving usa un servizio di bilanciamento del carico chiamato istio-ingressgateway, responsabile della gestione del traffico in entrata dall'esterno del cluster.

Per ottenere l'IP esterno per il 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 ha 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 EXTERNAL-IP è pending per un lungo periodo di tempo di seguito.

Controllo dello stato della revisione in corso...

Per ottenere la revisione più recente del servizio di pubblicazione Knative, esegui il seguente 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 ottenere lo stato completo:

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

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

  • Pronta indica se le risorse di runtime sono pronte. Se il valore è 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à della revisione è stato completato. Se status di questa condizione non è True, prova a controllare lo stato del pod.
  • Attiva indica se la revisione sta ricevendo traffico.

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

Controllo dello stato dei pod

Per ottenere i pod per tutti i tuoi deployment:

kubectl get pods

Dovresti vedere un elenco di tutti i pod con lo stato breve. 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 una e utilizza il seguente comando per visualizzare informazioni dettagliate sui suoi status. Alcuni campi utili sono conditions e containerStatuses:

kubectl get pod POD-NAME -o yaml

EXTERNAL-IP è <pending> per molto tempo

A volte potresti non ricevere un indirizzo IP esterno subito dopo la creazione per un cluster, ma vedi l'IP esterno come pending. Ad esempio, A questo scopo richiama il comando:

Per ottenere l'IP esterno per il bilanciatore del carico, esegui il seguente 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 ha 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 del traffico ASM in entrata che per impostazione predefinita è "istio-system". Si ottiene così un 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 che IN_USE_ADDRESSES quota è stata superata, puoi richiedere una quota aggiuntiva accedendo al IAM e pagina Amministrazione della console Google Cloud per e 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 a domini personalizzati e TLS gestito

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

Domini personalizzati per reti private interne

Se hai mappato un dominio personalizzato al tuo cluster o ai tuoi servizi Knative serving all'interno di un rete interna privata, devi disabilita i certificati TLS gestiti altrimenti la configurazione del tuo dominio non riuscirà a raggiungere lo stato ready. Di predefinita, il bilanciatore del carico interno non è in grado di comunicare esternamente l'autorità di certificazione.

Controllare lo stato di una mappatura di domini specifica

Per controllare lo stato di una mappatura dei domini 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 di yaml generati da questo comando, esamina la condizione di il campo CertificateProvisioned per determinare la natura dell'errore.

  3. Se viene visualizzato un errore, deve corrispondere a uno degli errori indicati nella tabelle seguenti. Segui i suggerimenti 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 Let's Encrypt è stata superata. Devi aumentare Crittografia quota dei certificati per quell'host.

InvalidDomainMappingName Messaggio: Il nome di DomainMapping %s non può essere uguale all'host dell'URL route %s.

Il nome di DomainMapping non può essere esattamente uguale all'host del percorso a cui è mappato. Utilizza un dominio diverso per il nome DomainMapping.

ChallengeServingErrored Messaggio: Il sistema non è riuscito a soddisfare 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.

  1. Assicurati che il servizio istio-ingressgateway sia accessibile dalla rete internet pubblica senza utilizzare Virtual Private Cloud.
  2. Assicurati che il tuo servizio istio-ingressgateway accetti 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 3 tipi di errori si verificano se la verifica della proprietà del dominio L'operazione di crittografia non riesce.

In genere questi errori sono temporanei e verranno riprovati dal servizio Knative.

Il ritardo del nuovo tentativo è esponenziale con un minimo di 8 secondi e un massimo di 8 ore.

Se vuoi riprovare manualmente a risolvere l'errore, puoi eliminare manualmente l'ordine non riuscito.

kubectl delete order DOMAIN -n NAMESPACE

ACMEAPIFailed Questo tipo di errore si verifica quando il servizio Knative non riesce a chiamare Let's Encrypt. In genere si tratta di un errore transitorio e verrà riprovato dal servizio Knative.

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 vedi questo, Contatta l'assistenza Cloud per ricevere aiuto per il debug.

Verifica 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, verifica 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.

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

Timeout ordine

Un oggetto Order scadrà dopo 20 minuti se ancora non riesce a ricevere certificati.

  1. Verifica lo stato della mappatura dei domini. Per un timeout, cerca un messaggio di errore simile al seguente nell'output dello 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 in uso all'indirizzo IP del servizio di ingresso. Esegui il seguente 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 per il bilanciatore del carico, esegui il seguente 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 ha 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 è il tuo indirizzo IP esterno del modulo di Google Cloud.

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

  4. Dopo l'applicazione del record DNS (aggiornato), esegui il seguente comando per eliminare l'oggetto Order in modo da 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 in modo globale in tempo. Di conseguenza, Let's Encrypt non riesce a verificare la proprietà del dominio.

  1. Controlla lo stato dell'ordine. Individua il link authz nel campo acmeAuthorizations dello stato. L'URL dovrebbe essere simile al seguente:

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

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

    urn:ietf:params:acme:error:dns

    il problema è dovuto a una 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 per il bilanciatore del carico, esegui il seguente 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 ha 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 del dominio eseguendo il seguente comando: 

      host DOMAIN

      Se l'indirizzo IP del record DNS non corrisponde all'IP esterno del dal bilanciatore del carico in entrata, configura il tuo record DNS mappare il dominio dell'utente all'IP esterno.

    3. Dopo che il record DNS (aggiornato) diventa effettivo, esegui il seguente comando per eliminare l'oggetto Order 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.

Errore di deployment in cluster privato: errore di chiamata del webhook non riuscito

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 al firewall necessarie per supportare il deployment in un ambiente consulta l'articolo sull'abilitazione dei deployment in un cluster privato.

Stato del report Servizi di IngressNotConfigured

Se nello stato del servizio viene visualizzato IngressNotConfigured, potrebbe essere necessario riavviare il deployment di istiod nello spazio dei nomi istio-system se utilizzi il control plane di Cloud Service Mesh all'interno del cluster. Questo errore, che è stato osservato più spesso su Kubernetes 1.14, può verificarsi se vengono creati prima che istiod sia pronto per iniziare il proprio lavoro di la riconciliazione di VirtualServices e il push della configurazione envoy al gateway in entrata.

Per risolvere il problema, esegui il ridimensionamento del deployment e poi di nuovo in modo inverso 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 relative al conteggio delle richieste e alla latenza delle richieste

Il tuo servizio potrebbe non registrare le metriche relative al numero di richieste di revisione e alla latenza delle richieste se hai attivato la federazione delle identità per i carichi di lavoro per GKE e non hai concesso determinate autorizzazioni all'account di servizio utilizzato dal tuo servizio.

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