Questa pagina fornisce strategie per la risoluzione dei problemi e soluzioni per alcuni errori comuni.
Quando risolvi i problemi di pubblicazione Knative, verifica innanzitutto di poter eseguire l'immagine container in locale.
Se la tua applicazione non viene eseguita in locale, dovrai diagnosticarla e correggerla. Usa Cloud Logging per eseguire il debug di un progetto di cui è stato eseguito il deployment.
Durante la risoluzione dei problemi relativi alla pubblicazione di Knative, consulta le sezioni seguenti per trovare possibili soluzioni.
Controllo dell'output della riga di comando in corso...
Se utilizzi Google Cloud CLI, controlla l'output comando per verificare se ha avuto esito positivo o negativo. Ad esempio, se il deployment non è stato completato correttamente, dovrebbe essere visualizzato un messaggio di errore che ne descrive il motivo.
Gli errori di deployment sono probabilmente dovuti a un manifest configurato in modo errato o a un comando errato. Ad esempio, l'output seguente indica che devi configurare la percentuale di traffico delle 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
Puoi utilizzare Cloud Logging o la pagina di gestione di Knative nella console Google Cloud per controllare i log delle richieste e i log dei container. Per i dettagli completi, consulta Logging e visualizzazione dei log.
Se utilizzi Cloud Logging, la risorsa in base a cui devi applicare un filtro è Container Kubernetes.
Controllo dello stato del servizio in corso...
Esegui questo comando per ottenere lo stato di un servizio di gestione Knative 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 di 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 per ricevere traffico. - ConfigurationReady:
True
indica che la Configuration sottostante è pronta. PerFalse
oUnknown
, dovresti visualizzare lo stato dell'ultima revisione. - RoutesReady:
True
indica che la Route sottostante è pronta. PerFalse
oUnknown
, dovresti visualizzare lo stato del percorso.
Per ulteriori dettagli sulle condizioni di stato, consulta Knative Error Signaling.
Controllo dello stato del percorso in corso...
Ogni servizio di gestione Knative gestisce una route che rappresenta lo stato di routing attuale rispetto alle revisioni del servizio.
Puoi controllare lo stato generale del percorso osservando 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 questo comando:
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 è
true
, la route è configurata correttamente.AllTrafficAssigned indica se il servizio è configurato correttamente e dispone di backend. Se
status
di questa condizione non èTrue
:Prova a controllare se la suddivisione del traffico tra le revisioni del servizio è pari al 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 le revisioni che ricevono traffico.
IngressReady indica se la risorsa Ingress è pronta. Se
status
di questa condizione non èTrue
, prova a controllare lo stato in entrata.CertificateProvisioned indica se è stato eseguito il provisioning dei certificati Knative. Se
status
di questa condizione non èTrue
, prova a risolvere i problemi di TLS gestito.
Per ulteriori dettagli sulle condizioni dello stato, consulta Report e condizioni di errore di Knative.
Controllo dello stato in entrata in corso...
Knative Serving utilizza un servizio di bilanciamento del carico chiamato
istio-ingressgateway
, responsabile della gestione del traffico in entrata
dall'esterno del cluster.
Per ottenere l'indirizzo 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 il traffico in entrata di Anthos Service Mesh. Specifica istio-system
se hai installato Anthos Service Mesh utilizzando la sua 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 il valore di EXTERNAL-IP è pending
, consulta la sezione EXTERNAL-IP è pending
per un periodo di tempo prolungato di seguito.
Controllo dello stato della revisione in corso...
Per ottenere la revisione più recente per il tuo servizio di gestione Knative, esegui questo comando:
gcloud run services describe SERVICE --format='value(status.latestCreatedRevisionName)'
Esegui questo comando per ottenere lo stato di una specifica revisione della pubblicazione di Knative:
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
indicano i motivi di un errore. Vale a dire:
- Pronta 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
status
di questa condizione non èTrue
, prova a controllare lo stato del pod. - ContainerHealthy indica se il controllo dell'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 il valore di status
per una di queste condizioni non è True
, prova a controllare lo stato del pod.
Controllo dello stato del pod
Per recuperare i pod per tutti i tuoi deployment:
kubectl get pods
In questo modo dovrebbero essere elencati tutti i pod con uno 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 comando seguente per visualizzare informazioni dettagliate relative a status
. Alcuni campi utili sono conditions
e containerStatuses
:
kubectl get pod POD-NAME -o yaml
L'IP ESTERNO è <pending>
per molto tempo
A volte, potresti non ottenere un indirizzo IP esterno subito dopo aver creato un cluster, ma visualizzare invece l'IP esterno come pending
. Ad esempio potresti vedere questo richiamando il comando:
Per ottenere l'indirizzo 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 il traffico in entrata di Anthos Service Mesh. Specifica istio-system
se hai installato Anthos Service Mesh utilizzando la sua 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ò può significare che hai esaurito la quota di indirizzi IP esterni in Google Cloud. Puoi verificare la possibile causa richiamando:
kubectl describe svc istio-ingressgateway -n INGRESS_NAMESPACEdove INGRESS_NAMESPACE è lo spazio dei nomi del traffico in entrata ASM che per impostazione predefinita è "istio-system". Questo restituisce 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 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 verrà assegnato un indirizzo IP esterno. L'operazione potrebbe richiedere alcuni minuti.
Risoluzione dei problemi relativi a domini personalizzati e TLS gestito
Segui i passaggi di risoluzione dei problemi elencati di seguito per risolvere i problemi generali per i domini personalizzati e la funzionalità dei certificati TLS gestiti.
Domini personalizzati per reti interne private
Se hai mappato un dominio personalizzato al tuo cluster o servizi Knative all'interno di una rete interna privata, devi disabilitare i certificati TLS gestiti, altrimenti la configurazione del dominio non riuscirà a raggiungere 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:
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 il mapping di dominio.
Nei risultati
yaml
di questo comando, esamina la condizione del campoCertificateProvisioned
per determinare la natura dell'errore.Se viene visualizzato un errore, dovrebbe corrispondere a uno degli errori nelle 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. Occorre mappare il dominio [XXX] all'IP XX.XX.XX.XX
Segui le istruzioni fornite per configurare correttamente il tuo record DNS. |
RateLimitExceeded | Messaggio:
acme: urn:ietf:params:acme:error:rateLimited: Errore durante la creazione di un nuovo ordine
:: troppi certificati già emessi per l'insieme esatto di domini: test.your-domain.com: consulta la pagina https://letsencrypt.org/docs/rate-limits/ La quota di Let's Encrypt è stata superata. Devi aumentare la quota dei certificati Let's Encrypt per quell'host. |
InvalidDomainMappingName | Messaggio:
Il nome DomainMapping %s non può essere uguale all'host dell'URL di route %s.
Il nome DomainMapping non può essere esattamente uguale all'host della route a cui è mappato. Utilizza un dominio diverso per il tuo nome DomainMapping. |
ChallengeServingErrored | Messaggio: Il sistema non è riuscito a gestire la richiesta HTTP01.
Questo errore può verificarsi se il servizio
|
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.
In genere questi errori sono temporanei e verranno tentati nuovamente dalla pubblicazione Knative. Il ritardo tra tentativi è esponenziale con un minimo di 8 secondi e un massimo di 8 ore. Se vuoi riprovare manualmente l'errore, puoi eliminare manualmente l'ordine non riuscito.
|
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 temporaneo che verrà riprovato dalla pubblicazione Knative.
Se vuoi riprovare manualmente l'errore, elimina l'ordine non riuscito.
|
UnknownErrored | Questo errore indica un errore di sistema sconosciuto, che dovrebbe verificarsi molto raramente nel cluster GKE. Se vedi questo messaggio, contatta l'assistenza Cloud per ricevere aiuto per il debug. |
Controllare lo stato dell'ordine
Lo stato dell'ordine registra il processo di interazione con Let's Encrypt. Di conseguenza, 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 il mapping di dominio.
I risultati conterranno i certificati emessi e altre informazioni se l'ordine è andato a buon fine.
Timeout ordine
Timeout di un oggetto Order dopo 20 minuti, se non è ancora in grado di ricevere i certificati.
Verifica lo stato della mappatura del dominio. Per un timeout, cerca nell'output di stato un messaggio di errore simile al seguente:
order (test.your-domain.com) timed out (20.0 minutes)
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 in entrata. Esegui questo comando per verificare il record DNS:
host DOMAIN
Controlla l'indirizzo IP esterno del bilanciatore del carico in entrata:
Per ottenere l'indirizzo 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 il traffico in entrata di Anthos Service Mesh. Specifica
istio-system
se hai installato Anthos Service Mesh utilizzando la sua 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.
Una volta che il record DNS (aggiornato) diventa effettivo, esegui questo comando 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 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.
Controlla lo stato dell'ordine. Trova il link di autorizzazione sotto il campo di stato
acmeAuthorizations
. L'URL dovrebbe avere il seguente aspetto:https://acme-v02.api.letsencrypt.org/acme/authz-v3/1717011827
Apri il link. Se viene visualizzato un messaggio simile al seguente:
urn:ietf:params:acme:error:dns
il problema è dovuto alla propagazione del DNS incompleta.
Per risolvere l'errore di propagazione del DNS:
Controlla l'indirizzo IP esterno del bilanciatore del carico in entrata:
Per ottenere l'indirizzo 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 il traffico in entrata di Anthos Service Mesh. Specifica
istio-system
se hai installato Anthos Service Mesh utilizzando la sua 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.
Verifica il record DNS del 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 per mappare il dominio dell'utente all'IP esterno.
Una volta che il record DNS (aggiornato) diventa effettivo, esegui questo comando 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 che utilizzi per il mapping di dominio.
Deployment nel cluster privato non riuscito: 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 al firewall necessarie per supportare il deployment in un cluster privato, consulta l'articolo sull'abilitazione dei deployment su un cluster privato.
Stato del report sui servizi di IngressNotConfig
Se nello stato del servizio viene visualizzato IngressNotConfigured
, potrebbe essere necessario riavviare il deployment di istiod
nello spazio dei nomi istio-system
se utilizzi Anthos Service Mesh del piano di controllo nel cluster. Questo errore, osservato più di frequente su Kubernetes 1.14
, può verificarsi se i servizi vengono creati prima che istiod
sia pronto per iniziare il lavoro di riconciliazione di VirtualServices
e di push della configurazione envoy sui gateway in entrata.
Per risolvere il problema, fai lo scale in e poi il deployment del deployment di nuovo utilizzando comandi simili ai seguenti:
kubectl scale deployment istiod -n istio-system --replicas=0
kubectl scale deployment istiod -n istio-system --replicas=1
Mancano metriche di conteggio delle richieste e latenza delle richieste
Il servizio potrebbe non segnalare le metriche relative al conteggio delle richieste di revisione e alla latenza delle richieste se hai abilitato Workload Identity e non hai concesso determinate autorizzazioni all'account di servizio utilizzato dal tuo servizio.
Puoi risolvere il problema seguendo i passaggi nella sezione Abilitazione delle metriche su un cluster con Workload Identity.