Questa pagina fornisce strategie di risoluzione dei problemi e soluzioni per 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 localmente, dovrai diagnosticarla e correggerla. Ti consigliamo di utilizzare Cloud Logging per eseguire il debug di un progetto di cui è stato eseguito il deployment.
Quando risolvi i problemi relativi a Knative Serving, consulta le sezioni seguenti per trovare possibili soluzioni al problema.
Controllare l'output della riga di comando
Se utilizzi Google Cloud CLI, controlla l'output del comando per verificare se è andato a buon fine. Ad esempio, se il deployment è terminato senza successo, dovrebbe essere presente un messaggio di errore che descrive il motivo del problema.
I problemi di deployment sono molto probabilmente dovuti a un manifest configurato in modo errato o a un comando non corretto. Ad esempio, l'output seguente indica che devi configurare la percentuale di traffico della 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 Knative Serving nella Google Cloud console per controllare i log delle richieste e i log dei container. Per informazioni complete, consulta la sezione Registrazione e visualizzazione dei log.
Se utilizzi Cloud Logging, la risorsa su cui devi filtrare è Container Kubernetes.
Controllare lo stato del servizio
Esegui il comando seguente 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 ottenere lo stato completo, ad esempio:
gcloud run services describe SERVICE --format 'yaml(status)'
Le condizioni in status possono aiutarti a individuare la causa del problema.
Le condizioni possono includere True, False o Unknown:
- Pronto:
Trueindica che il servizio è configurato e pronto a ricevere traffico. - ConfigurationReady:
Trueindica che la configurazione sottostante è pronta. PerFalseoUnknown, devi visualizzare lo stato dell'ultima revisione. - RoutesReady:
Trueindica che la route sottostante è pronta. PerFalseoUnknown, devi visualizzare lo stato della route.
Per ulteriori dettagli sulle condizioni di stato, consulta la sezione Segnalazione degli errori di Knative.
Controllare lo stato della route
Ogni servizio Knative Serving gestisce una route che rappresenta lo stato di routing corrente rispetto alle revisioni del servizio.
Puoi controllare lo stato generale della route 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 comando seguente:
kubectl get route SERVICE -o yaml
Le condizioni in status forniscono il motivo di un problema. Vale a dire:
Ready 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
statusdi questa condizione non èTrue:Prova a verificare 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
gcloud run services update-trafficcomando.Prova a controllare lo stato della revisione per le revisioni che ricevono traffico.
IngressReady indica se l'ingresso è pronto. Se
statusdi questa condizione non èTrue, prova a controllare lo stato dell'ingresso.CertificateProvisioned indica se i certificati Knative sono stati sottoposti a provisioning. Se
statusdi questa condizione non èTrue, prova a risolvere i problemi relativi a TLS gestito.
Per ulteriori dettagli sulle condizioni di stato, consulta la sezione Condizioni e report degli errori di Knative.
Controllare lo stato dell'ingresso
Knative Serving utilizza un servizio di bilanciamento del carico denominato istio-ingressgateway, responsabile della gestione del traffico in entrata dall'esterno del cluster.
Per ottenere l'IP esterno del bilanciatore del carico, esegui il comando seguente:
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 la sezione
L'IP esterno è pending da molto tempo di seguito.
Controllare lo stato della revisione
Per ottenere l'ultima revisione del servizio Knative Serving, esegui il comando seguente:
gcloud run services describe SERVICE --format='value(status.latestCreatedRevisionName)'
Esegui il comando seguente per ottenere lo stato di una revisione specifica di Knative Serving:
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 problema. Vale a dire:
- Ready 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
statusdi questa condizione non èTrue, prova a controllare lo stato del pod. - ContainerHealthy indica se il controllo di idoneità della revisione è stato completato.
Se
statusdi questa condizione non èTrue, prova a controllare lo stato del pod. - Active indica se la revisione riceve traffico.
Se status di una di queste condizioni non è True, prova a controllare lo stato del pod.
Controllare lo stato del pod
Per ottenere i pod per tutti i deployment:
kubectl get pods
Dovrebbe essere visualizzato un 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 un pod e utilizza il comando seguente per visualizzare informazioni dettagliate sul relativo status. Alcuni campi utili sono conditions e containerStatuses:
kubectl get pod POD-NAME -o yaml
L'IP esterno è <pending> da molto tempo
A volte, potresti non ricevere immediatamente un indirizzo IP esterno dopo aver creato un cluster, ma visualizzare l'IP esterno come pending. Ad esempio, potresti visualizzare questo messaggio richiamando il comando:
Per ottenere l'IP esterno del bilanciatore del carico, esegui il comando seguente:
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.
Questo 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 la IN_USE_ADDRESSES quota è stata superata, puoi richiedere una quota aggiuntiva accedendo alla pagina IAM e Amministrazione nella Google Cloud console per richiedere una quota aggiuntiva.
Il gateway continuerà a riprovare finché non viene assegnato un indirizzo IP esterno. L'operazione potrebbe richiedere alcuni minuti.
Risolvere i 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à dei certificati TLS gestiti.
Domini personalizzati per reti interne private
Se hai mappato un dominio personalizzato al cluster o ai servizi Knative Serving
all'interno di una
rete interna privata,
devi
disabilitare 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:
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 di dominio.
Nei risultati
yamldi questo comando, esamina la condizione del campoCertificateProvisionedper 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. Devi 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 di certificati Let's Encrypt per questo host. |
| InvalidDomainMappingName | Messaggio:
Il nome della mappatura di dominio %s non può essere uguale all'host dell'URL della route %s.
Il nome della mappatura di dominio non può essere esattamente uguale all'host della route a cui esegue la mappatura. Utilizza un dominio diverso per il nome della mappatura di dominio. |
| 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 riesce.
In genere si tratta di errori temporanei, che verranno riprovati da Knative Serving. Il ritardo di ripetizione è 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.
|
| ACMEAPIFailed | Questo tipo di errore si verifica quando Knative Serving non riesce a chiamare
Let's Encrypt. In genere si tratta di un errore temporaneo, che verrà riprovato da
Knative Serving.
Se vuoi riprovare manualmente a risolvere 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. |
Controllare lo stato dell'ordine
Lo stato dell'ordine registra il processo di interazione con Let's Encrypt e può quindi 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 di dominio.
Se l'ordine è andato a buon fine, i risultati conterranno i certificati emessi e altre informazioni.
Timeout dell'ordine
Un oggetto Order andrà in timeout dopo 20 minuti se non riesce ancora a ottenere i certificati.
Controlla lo stato della mappatura di dominio. Per un timeout, cerca un messaggio di errore simile a 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 che stai utilizzando all'indirizzo IP del servizio di ingresso. Esegui il comando seguente per controllare il record DNS:
host DOMAINControlla l'indirizzo IP esterno del bilanciatore del carico di ingresso:
Per ottenere l'IP esterno del bilanciatore del carico, esegui il comando seguente:
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-systemse 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 esegua la mappatura all'indirizzo IP corretto.
Dopo che il record DNS (aggiornato) diventa effettivo, esegui il comando seguente per eliminare l'oggetto Order in modo da 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 authz nel campo
acmeAuthorizationsdello stato. L'URL dovrebbe essere simile al seguente:https://acme-v02.api.letsencrypt.org/acme/authz-v3/1717011827
Apri il link. Se visualizzi un messaggio simile a:
urn:ietf:params:acme:error:dns
il problema è dovuto alla propagazione DNS incompleta.
Per risolvere l'errore di propagazione DNS:
Controlla l'indirizzo IP esterno del bilanciatore del carico di ingresso:
Per ottenere l'IP esterno del bilanciatore del carico, esegui il comando seguente:
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-systemse 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 per il dominio eseguendo il comando seguente:
host DOMAINSe l'indirizzo IP del record DNS non corrisponde all'IP esterno del bilanciatore del carico di ingresso, configura il record DNS in modo che esegua la mappatura del dominio dell'utente all'IP esterno.
Dopo che il record DNS (aggiornato) diventa effettivo, esegui il comando seguente per eliminare l'oggetto Order in modo da 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 la mappatura di dominio.
Problema di deployment nel cluster privato: errore di chiamata del webhook
Il firewall potrebbe non essere configurato correttamente se il deployment in un cluster privato non riesce 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 del firewall necessarie per supportare il deployment in un cluster privato, consulta la sezione Abilitare i deployment in un cluster privato.
I servizi segnalano lo stato IngressNotConfigured
Se IngressNotConfigured viene visualizzato nello stato del servizio, potrebbe essere necessario
riavviare il deployment istiod nello spazio dei nomi istio-system se utilizzi il control plane 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 di ingresso.
Per risolvere il problema, esegui lo scale up e poi lo scale down 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 relative al conteggio delle richieste e alla latenza delle richieste mancanti
Il servizio potrebbe non segnalare le metriche relative al conteggio delle richieste di revisione e alla latenza delle richieste se hai abilitato Workload Identity Federation for GKE e non hai concesso determinate autorizzazioni al account di servizio utilizzato dal servizio.
Puoi risolvere il problema seguendo i passaggi descritti nella sezione Abilitare le metriche su un cluster con Workload Identity Federation for GKE.