Questa pagina è stata tradotta dall'API Cloud Translation.

Deployment di proxy API non riusciti con avviso Nessun pod di runtime attivo

Stai visualizzando la documentazione di Apigee e Apigee hybrid.
Visualizza Documentazione di Apigee Edge.

Sintomi

I deployment dei proxy API non riescono con l'avviso Nessun pod di runtime attivo nell'UI ibrida di Apigee.

Messaggi di errore

L'avviso Nessun pod di runtime attivo viene visualizzato nella finestra di dialogo Dettagli accanto al messaggio di errore Problemi di deployment su ENVIRONMENT:REVISION_NUMBER nella pagina del proxy API:

Questo problema può manifestarsi come errori diversi in altre pagine di risorse dell'interfaccia utente. Ecco alcuni messaggi di errore di esempio:

Messaggio di errore n. 1 dell'interfaccia utente ibrida: errore Datastore

Potresti notare l'errore del datastore nelle pagine API Products e Apps dell'interfaccia utente ibrida, come mostrato di seguito:

Messaggio di errore 2 dell'interfaccia utente ibrida: errore interno del server

Potresti notare un errore interno del server nella pagina Sviluppatori dell'interfaccia utente, come mostrato di seguito:

Output del comando Kubectl

Potresti notare che gli stati dei pod apiege-mart, apigee-runtime e apigee- synchronizer vengono modificati in CrashLoopBackOff nell'output del comando kubectl get pods:

Messaggi di errore del log dei componenti

Nel apigee-runtime osserverai i seguenti errori di errore del probe di attività log dei pod nelle release ibride di Apigee >= 1.4.0:

{"timestamp":"1621575431454","level":"ERROR","thread":"qtp365724939-205","mdc":{"targetpath":"/v1/pr
obes/live"},"logger":"REST","message":"Error occurred : probe failed Probe cps-datastore-
connectivity-liveliness-probe failed due to com.apigee.probe.model.ProbeFailedException{ code =
cps.common.datastoreConnectionNotHealthy, message = Datastore connection not healthy, associated
contexts =
[]}\n\n\tcom.apigee.probe.ProbeAPI.getResponse(ProbeAPI.java:66)\n\tcom.apigee.probe.ProbeAPI.getLiv
eStatus(ProbeAPI.java:55)\n\tsun.reflect.GeneratedMethodAccessor52.invoke(Unknown
Source)\n\tsun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)\n\t
","context":"apigee-service-
logs","severity":"ERROR","class":"com.apigee.rest.framework.container.ExceptionMapper","method":"toR
esponse"}

{"timestamp":"1621575431454","level":"ERROR","thread":"qtp365724939-205","mdc":{"targetpath":"/v1/pr
obes/live"},"logger":"REST","message":"Returning error response : ErrorResponse{errorCode =
probe.ProbeRunError, errorMessage = probe failed Probe cps-datastore-connectivity-liveliness-probe
failed due to com.apigee.probe.model.ProbeFailedException{ code =
cps.common.datastoreConnectionNotHealthy, message = Datastore connection not healthy, associated
contexts = []}}","context":"apigee-service-
logs","severity":"ERROR","class":"com.apigee.rest.framework.container.ExceptionMapper","method":"toR
esponse"}

Nei log del pod delle release di Apigee hybrid >= 1.4.0 vedrai il seguente Cannot build a cluster without contact points errore:

{"timestamp":"1621575636434","level":"ERROR","thread":"main","logger":"KERNEL.DEPLOYMENT","message":
"ServiceDeployer.deploy() : Got a life cycle exception while starting service [SyncService, Cannot
build a cluster without contact points] : {}","context":"apigee-service-
logs","exception":"java.lang.IllegalArgumentException: Cannot build a cluster without contact
points\n\tat com.datastax.driver.core.Cluster.checkNotEmpty(Cluster.java:134)\n\tat
com.datastax.driver.core.Cluster.<init>(Cluster.java:127)\n\tat
com.datastax.driver.core.Cluster.buildFrom(Cluster.java:193)\n\tat
com.datastax.driver.core.Cluster$Builder.build(Cluster.java:1350)\n\tat
io.apigee.persistence.PersistenceContext.newCluster(PersistenceContext.java:214)\n\tat
io.apigee.persistence.PersistenceContext.<init>(PersistenceContext.java:48)\n\tat
io.apigee.persistence.ApplicationContext.<init>(ApplicationContext.java:19)\n\tat
io.apigee.runtimeconfig.service.RuntimeConfigServiceImpl.<init>(RuntimeConfigServiceImpl.java:75)
\n\tat
io.apigee.runtimeconfig.service.RuntimeConfigServiceFactory.newInstance(RuntimeConfigServiceFactory.
java:99)\n\tat
io.apigee.common.service.AbstractServiceFactory.initializeService(AbstractServiceFactory.java:301)\n
\tat
...","severity":"ERROR","class":"com.apigee.kernel.service.deployment.ServiceDeployer","method":"sta
rtService"}

Nei log del pod apigee-mart delle release ibride di Apigee >= 1.4.0 vedrai i seguenti errori di mancata verifica della funzionalità:

{"timestamp":"1621576757592","level":"ERROR","thread":"qtp991916558-144","mdc":{"targetpath":"/v1/pr
obes/live"},"logger":"REST","message":"Error occurred : probe failed Probe cps-datastore-
connectivity-liveliness-probe failed due to com.apigee.probe.model.ProbeFailedException{ code =
cps.common.datastoreConnectionNotHealthy, message = Datastore connection not healthy, associated
contexts =
[]}\n\n\tcom.apigee.probe.ProbeAPI.getResponse(ProbeAPI.java:66)\n\tcom.apigee.probe.ProbeAPI.getLiv
eStatus(ProbeAPI.java:55)\n\tsun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)\n\tsun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)\n\t","conte
xt":"apigee-service-
logs","severity":"ERROR","class":"com.apigee.rest.framework.container.ExceptionMapper","method":"toR
esponse"}

{"timestamp":"1621576757593","level":"ERROR","thread":"qtp991916558-144","mdc":{"targetpath":"/v1/pr
obes/live"},"logger":"REST","message":"Returning error response : ErrorResponse{errorCode =
probe.ProbeRunError, errorMessage = probe failed Probe cps-datastore-connectivity-liveliness-probe
failed due to com.apigee.probe.model.ProbeFailedException{ code =
cps.common.datastoreConnectionNotHealthy, message = Datastore connection not healthy, associated
contexts = []}}","context":"apigee-service-
logs","severity":"ERROR","class":"com.apigee.rest.framework.container.ExceptionMapper","method":"toR
esponse"}

Informazioni sull'errore Nessun pod di runtime attivo

Nella release Apigee hybrid 1.4.0, la funzionalità di probe di attività è stata aggiunta ai pod apigee-runtime e apigee-mart per controllare lo stato dei pod Cassandra. Se tutti i pod Cassandra non sono più disponibili, i probe di attività del apigee-runtime e apigee-mart pod non riusciranno. Di conseguenza, i pod apigee-runtime e apigee-mart passeranno allo stato CrashLoopBackOff , causando il fallimento dei deployment dei proxy API con l'avviso No active runtime pods. Anche il pod apigee-synchronizer passerà allo stato CrashLoopBackOff a causa della mancata disponibilità dei pod Cassandra.

Cause possibili

Ecco alcune possibili cause di questo errore:

Causa	Descrizione
I pod di Cassandra non sono attivi	I pod Cassandra non sono attivi; pertanto, i pod `apigee-runtime` non potranno comunicare con il database Cassandra.
Replica Cassandra configurata con un solo pod	Avere un solo pod Cassandra potrebbe diventare un single point of failure.

Causa: i pod Cassandra non sono attivi

Durante il processo di implementazione del proxy API, i pod apigee-runtime si connettono al database Cassandra per recuperare le risorse, ad esempio le mappe di valori chiave (KVM) e le cache, definite nel proxy API. Se non sono in esecuzione pod Cassandra, i pod apigee-runtime non potranno connettersi al database Cassandra. Ciò comporta il fallimento del deployment del proxy API.

Diagnosi

Elenca i pod Cassandra:

kubectl -n apigee get pods -l app=apigee-cassandra

Esempio di output 1:

NAME                         READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   0/1     Pending   0          9m23s

Nota: questo output di esempio mostra che il pod Cassandra si trova nello stato Pending.

Esempio di output 2:

NAME                 READY   STATUS            RESTARTS   AGE
apigee-cassandra-0   0/1     CrashLoopBackoff  0          10m

Nota: questo output di esempio mostra che il pod Cassandra si trova nello stato CrashLoopBackoff.

Verifica lo stato di ogni pod Cassandra. Lo stato di tutti i pod Cassandra deve essere in stato Running. Se uno dei pod Cassandra è in uno stato diverso, potrebbe essere la causa del problema. Per risolvere il problema, procedi nel seguente modo:

Risoluzione

Se uno dei pod Cassandra è nello stato Pending, consulta I pod Cassandra sono bloccati nello stato In attesa per risolvere il problema.

Se uno dei pod di Cassandra è in stato CrashLoopBackoff, fai riferimento a I pod Cassandra sono bloccati nello stato CrashLoopBackoff per risolvere il problema.

Nota: una volta che i pod Cassandra sono in stato integro, apigee-runtime, apigee-mart e apigee-synchronizer i pod verranno ripristinati e il loro stato cambierà in Running.

Esempio di output:

kubectl -n apigee get pods -l app=apigee-runtime
NAME                                                           READY   STATUS    RESTARTS   AGE
apigee-runtime-apigee-hybrid-s-test1-8b64f12-143-501i7-2gnch   1/1     Running   13         43m
apigee-runtime-apigee-hybrid-s-test1-8b64f12-143-501i7-42jdv   1/1     Running   13         45m
apigee-runtime-apigee-hybrid-s-test1-8b64f12-143-501i7-l7wq7   1/1     Running   13         43m
apigee-runtime-apigee-hybrid-s-test1-8b64f12-143-501i7-q2thb   1/1     Running   8          38m

kubectl -n apigee get pods -l app=apigee-mart
NAME                                                  READY   STATUS    RESTARTS   AGE
apigee-mart-apigee-hybrid-s-2664b3e-143-u0a5c-rtg69   2/2     Running   8          28m

kubectl -n apigee get pods -l app=apigee-synchronizer
NAME                                                              READY   STATUS    RESTARTS   AGE
apigee-synchronizer-apigee-hybrid-s-test1-8b64f12-143-96zp269nb   2/2     Running   10         29m
apigee-synchronizer-apigee-hybrid-s-test1-8b64f12-143-96zp2w2jp   2/2     Running   0          4m40s
apigee-synchronizer-apigee-hybrid-s-test1-8b64f12-143-96zpkfkvq   2/2     Running   0          4m40s
apigee-synchronizer-apigee-hybrid-s-test1-8b64f12-143-96zpxmzhn   2/2     Running   0          4m40s

Causa: replica Cassandra configurata con un solo pod

Se il conteggio delle repliche Cassandra è configurato su uno, sarà disponibile un solo pod Cassandra nel runtime. Di conseguenza, i pod apigee-runtime potrebbero riscontrare problemi di connettività se il pod Cassandra diventa non disponibile per un determinato periodo di tempo.

Diagnosi

Ottieni il set stateful Cassandra e controlla il conteggio attuale delle repliche:
```
kubectl -n apigee get statefulsets -l app=apigee-cassandra
```
Esempio di output:
```
NAME                               READY           AGE
apigee-cassandra-default           1/1             21m
```
Nota: l'output di esempio riportato sopra mostra che il conteggio delle repliche è configurato con un valore di 1 (fai riferimento al campo READY).
Se il conteggio delle repliche è configurato su 1, segui questi passaggi per aumentarlo un numero più alto.

Risoluzione

I deployment non di produzione di Apigee hybrid potrebbero avere impostato il numero di repliche Cassandra su 1. Se l'alta disponibilità di Cassandra è importante nei deployment non in produzione, aumenta il numero di repliche a 3 per risolvere il problema.

Per risolvere il problema, procedi nel seguente modo:

Aggiorna il file overrides.yaml e imposta il conteggio delle repliche Cassandra su 3:
```
cassandra:
  replicaCount: 3
```
Per informazioni sulla configurazione di Cassandra, consulta Riferimento per le proprietà di configurazione.
Applica la configurazione precedente utilizzando l'interfaccia a riga di comando apigeectl:
```
cd path/to/hybrid-files
apigeectl apply -f overrides/overrides.yaml
```

Ottieni il set stateful Cassandra e controlla il conteggio attuale delle repliche:

kubectl -n get statefulsets -l app=apigee-cassandra

Esempio di output:

NAME                              READY         AGE
apigee-cassandra-default          3/3           27m

Recupera i pod Cassandra e controlla il conteggio delle istanze attuali. Se non tutti i pod sono pronti e sono nello stato Running, attendi che i nuovi pod Cassandra vengano creati e attivati:

kubectl -n get pods -l app=apigee-cassandra

Esempio di output:

NAME                         READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          29m
apigee-cassandra-default-1   1/1     Running   0          21m
apigee-cassandra-default-2   1/1     Running   0          19m

Nota: una volta che i pod Cassandra diventano stabili, i pod apigee-runtime, apigee-mart e apigee-synchronizer si riprendono e il loro stato diventa Running.

Esempio di output:

kubectl -n apigee get pods -l app=apigee-runtime
NAME                                                           READY   STATUS    RESTARTS   AGE
apigee-runtime-apigee-hybrid-s-test1-8b64f12-143-501i7-2gnch   1/1     Running   13         43m
apigee-runtime-apigee-hybrid-s-test1-8b64f12-143-501i7-42jdv   1/1     Running   13         45m
apigee-runtime-apigee-hybrid-s-test1-8b64f12-143-501i7-l7wq7   1/1     Running   13         43m
apigee-runtime-apigee-hybrid-s-test1-8b64f12-143-501i7-q2thb   1/1     Running   8          38m

kubectl -n apigee get pods -l app=apigee-mart
NAME                                                  READY   STATUS    RESTARTS   AGE
apigee-mart-apigee-hybrid-s-2664b3e-143-u0a5c-rtg69   2/2     Running   8          28m

kubectl -n apigee get pods -l app=apigee-synchronizer
NAME                                                              READY   STATUS    RESTARTS   AGE
apigee-synchronizer-apigee-hybrid-s-test1-8b64f12-143-96zp269nb   2/2     Running   10         29m
apigee-synchronizer-apigee-hybrid-s-test1-8b64f12-143-96zp2w2jp   2/2     Running   0          4m40s
apigee-synchronizer-apigee-hybrid-s-test1-8b64f12-143-96zpkfkvq   2/2     Running   0          4m40s
apigee-synchronizer-apigee-hybrid-s-test1-8b64f12-143-96zpxmzhn   2/2     Running   0          4m40s

Deve raccogliere informazioni di diagnostica

Se il problema persiste anche dopo aver seguito le istruzioni riportate sopra, raccogli i seguenti dati le informazioni di diagnostica e contatta l'assistenza clienti Google Cloud.

ID progetto Google Cloud
Organizzazione ibrida/Apigee Apigee
Per Apigee hybrid: overrides.yaml, che maschera le informazioni sensibili

Stato del pod Kubernetes in tutti gli spazi dei nomi:

kubectl get pods -A > kubectl-pod-status`date +%Y.%m.%d_%H.%M.%S`.txt

Dump di informazioni sul cluster Kubernetes:

# generate kubernetes cluster-info dump
kubectl cluster-info dump -A --output-directory=/tmp/kubectl-cluster-info-dump
# zip kubernetes cluster-info dump
zip -r kubectl-cluster-info-dump`date +%Y.%m.%d_%H.%M.%S`.zip /tmp/kubectl-cluster-info-dump/*

Deployment di proxy API non riusciti con avviso Nessun pod di runtime attivo

Sintomi

Messaggi di errore

Messaggio di errore n. 1 dell'interfaccia utente ibrida: errore Datastore

Messaggio di errore 2 dell'interfaccia utente ibrida: errore interno del server

Output del comando Kubectl

Messaggi di errore del log dei componenti

Informazioni sull'errore Nessun pod di runtime attivo

Cause possibili

Causa: i pod Cassandra non sono attivi

Diagnosi

Risoluzione

Causa: replica Cassandra configurata con un solo pod

Diagnosi

Risoluzione

Deve raccogliere informazioni di diagnostica

Riferimenti