Questa pagina fornisce strategie di risoluzione dei problemi e soluzioni per alcuni errori comuni.
Quando risolvi i problemi di pubblicazione di Knative, verifica innanzitutto di poter eseguire l'immagine del contenitore localmente.
Se l'applicazione non è in esecuzione in locale, dovrai diagnosticarla e correggerla. Ti consigliamo di utilizzare Cloud Logging per eseguire 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 non è andato a buon fine, dovrebbe essere visualizzato un messaggio di errore 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 devi configurare la percentuale di traffico delle route in modo che la somma sia pari 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
Controllare i log del servizio
Puoi utilizzare Cloud Logging o la pagina di pubblicazione di Knative nella console Google Cloud per controllare i log delle richieste e i log dei container. Per informazioni dettagliate, consulta Generare e visualizzare i log.
Se utilizzi Cloud Logging, la risorsa su cui devi filtrare è 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
:
- Pronto:
True
indica che il servizio è configurato e pronto a ricevere il traffico. - ConfigurationReady:
True
indica che la configurazione di base è pronta. PerFalse
oUnknown
, devi visualizzare lo stato dell'ultima revisione. - RoutesReady:
True
indica che la route di base è pronta. PerFalse
oUnknown
, devi visualizzare lo stato della route.
Per ulteriori dettagli sulle condizioni di stato, consulta Knative Error Signaling.
Controllo dello stato del percorso
Ogni servizio di pubblicazione Knative gestisce una route che rappresenta lo stato attuale del routing 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 di un errore. Nello specifico:
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
:Prova a controllare se la suddivisione del traffico tra le revisioni per il tuo servizio corrisponde 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 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
Il servizio 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 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 di 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
EXTERNAL-IP è pending
per molto tempo di seguito.
Controllo dello stato della revisione
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 il seguente comando per ottenere lo stato di una revisione di servizio Knative 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. Nello specifico:
- Pronto 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
status
di questa condizione non èTrue
, prova a controllare lo stato del pod. - ContainerHealthy indica se il controllo di idoneità alla 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 status
di una di queste condizioni 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
Dovresti vedere l'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 uno e utilizza il seguente comando per visualizzare informazioni dettagliate sul relativo
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 immediatamente dopo aver creato un cluster, ma visualizzare l'IP esterno come pending
. Ad esempio, puoi verificarlo richiamando 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 di 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
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 indica che la quota IN_USE_ADDRESSES
è stata superata, puoi richiedere una quota aggiuntiva nella pagina IAM e amministrazione della console Google Cloud.
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
Segui i passaggi per la risoluzione dei problemi elencati di seguito per risolvere i problemi generali relativi ai domini personalizzati e alla 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
all'interno di una
rete interna privata,
devi
disattivare 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 dei domini 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 la mappatura del 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 riportati 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 Let's Encrypt è stata superata. Devi aumentare la quota dei certificati Let's Encrypt per l'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 altro dominio per il nome di DomainMapping. |
ChallengeServingErrored | Messaggio: Il sistema non è riuscito a soddisfare 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 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 correggere 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 e verrà riprovato dal servizio Knative.
Se vuoi riprovare manualmente l'errore, elimina manualmente l'ordine non riuscito.
|
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 assistenza per il debug. |
Verificare 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.
I risultati conterranno i certificati emessi e altre informazioni se l'ordine è andato a buon fine.
Timeout ordine
Un oggetto Order avrà un timeout dopo 20 minuti se non riesce ancora a ottenere i certificati.
Controlla lo stato della mappatura del dominio. In caso di timeout, cerca un messaggio di errore come questo nell'output dello stato:
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 in uso all'indirizzo IP del servizio di ingresso. Esegui il seguente comando per controllare il record DNS:
host DOMAIN
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 di 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 di ingresso, riconfigura il record DNS in modo che mappi all'indirizzo IP corretto.
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.
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
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.
Per risolvere l'errore di propagazione DNS:
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 di 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.
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 bilanciatore del carico in entrata, configura il record DNS in modo da mappare il dominio dell'utente all'IP esterno.
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 implementazione nel cluster privato: errore di chiamata all'webhook
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 alla firewall necessarie per supportare il deployment in un cluster privato, vedi Attivare i 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 piano di controllo in-cluster di Cloud Service Mesh. Questo errore,
che è stato osservato più di frequente 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 invio della configurazione di Envoy ai gateway di ingresso.
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 Workload Identity Federation for GKE e non hai concesso determinate autorizzazioni all'account di servizio utilizzato dal tuo servizio.
Per risolvere il problema, segui i passaggi descritti nella sezione Abilitazione delle metriche in un cluster con la federazione delle identità per i carichi di lavoro per GKE.