Estás viendo la documentación de Apigee y Apigee Hybrid.
    Consulta la documentación de Apigee Edge.
  
Síntomas
Las implementaciones de proxies de API fallan con una advertencia Sin pods del entorno de ejecución activos en la IU híbrida de Apigee.
Mensajes de error
La advertencia Sin Pods del entorno de ejecución activos se muestra en el diálogo Detalles junto al mensaje de error Problemas de implementación en ENVIRONMENT: REVISION_NUMBER en la página del proxy de API:
 
  Este problema se puede manifestar como errores diferentes en otras páginas de recursos de la IU. Estos son algunos mensajes de error de ejemplo:
Mensaje de error de IU híbrida n.º 1: Error de Datastore
Puedes observar el Error de Datastore en las páginas Productos de API y Aplicaciones de la IU híbrida, como se muestra a continuación:
 
Mensaje de error de IU híbrida n.º 2: Error interno del servidor
Puedes observar el error interno del servidor en la página Desarrolladores de la IU como se muestra a continuación:
 
Resultado del comando de Kubectl
    Es posible que observes que los estados de Pods apiege-mart, apigee-runtime y apigee-
    synchronizer se cambian a CrashLoopBackOff  en el resultado del comando kubectl get pods:
  
 
Mensajes de error de registro de componentes
    Observarás los siguientes errores de falla del sondeo de funcionamiento en los registros del Pod apigee-runtime en las versiones de Apigee Hybrid >= 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"}
    Observarás el siguiente error Cannot build a cluster without contact points  en los registros del pod apigee-synchronizer en las versiones de Apigee Hybrid >= 1.4.0:
  
{"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"}
    Verás los siguientes errores de falla del sondeo de funcionamiento en los registros del pod apigee-mart en versiones de Apigee Hybrid >= 1.4.0:
  
{"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"}Información sobre el error Sin pods de entorno de ejecución activos
    En la versión 1.4.0 de Apigee Hybrid, la función de sondeo de funcionamiento se agregó a los Pods apigee-runtime y apigee-mart para verificar el estado de los Pods de Cassandra. Si todos los pods de Cassandra dejan de estar disponibles, los sondeos de funcionamiento de los pods apigee-runtime y apigee-mart  fallarán.  Por lo tanto, los pods apigee-runtime  y apigee-mart  entrarán en el estado CrashLoopBackOff , lo que hará que las implementaciones de proxies de API fallen con la advertencia No active runtime pods.
    El pod apigee-synchronizer también cambiará al estado CrashLoopBackOff  debido a que los pods de Cassandra no están disponibles.
  
Causas posibles
A continuación, se indican algunas de las posibles causas de este error:
| Causa | Descripción | 
|---|---|
| Los pods de Cassandra están inactivos | Los pods de Cassandra están inactivos; por lo tanto, los pods apigee-runtimeno podrán comunicarse con la base de datos de Cassandra. | 
| La réplica de Cassandra está configurada con un solo pod | Tener un solo Pod de Cassandra podría convertirse en un punto único de fallo. | 
Causa: los pods de Cassandra están inactivos
    Durante el proceso de implementación del proxy de API, los pods apigee-runtime se conectan a la base de datos de Cassandra para recuperar recursos, como mapas de clave-valor (KVM) y memorias caché, definidos en el proxy de API. Si no hay pods de Cassandra en ejecución, los pods apigee-runtime no podrán conectarse a la base de datos de Cassandra. Esto genera una falla en la implementación del proxy de API.
  
Diagnóstico
- Enumera los Pods de Cassandra:
kubectl -n apigee get pods -l app=apigee-cassandra Resultado de muestra 1: NAME READY STATUS RESTARTS AGE apigee-cassandra-default-0 0/1 Pending 0 9m23s Resultado de muestra 2: NAME READY STATUS RESTARTS AGE apigee-cassandra-0 0/1 CrashLoopBackoff 0 10m 
- Verifica el estado de cada pod de Cassandra. El estado de todos los pods de Cassandra debe ser Running. Si alguno de los pods de Cassandra está en un estado diferente, ese podría ser el motivo de este problema. Sigue estos pasos para intentar resolver el problema:
Solución
- Si alguno de los pods de Cassandra está en el estado Pending, consulta Los pods de Cassandra están atascados en el estado pendiente para solucionar y resolver el problema.
- Si alguno de los pods de Cassandra está en el estado CrashLoopBackoff, consulta Los pods de Cassandra están atascados en el estado CrashLoopBackoff para solucionar el problema y resolverlo.Resultado de muestra: 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: la réplica de Cassandra está configurada con un solo pod
    Si el recuento de réplicas de Cassandra está configurado en uno, solo habrá un pod de Cassandra disponible en el entorno de ejecución. Como resultado, los pods apigee-runtime pueden experimentar problemas de conectividad si ese pod de Cassandra deja de estar disponible durante un período determinado.
  
Diagnóstico
- Obtén el conjunto con estado de Cassandra y verifica el recuento de réplicas actual:
kubectl -n apigee get statefulsets -l app=apigee-cassandra Resultado de muestra: NAME READY AGE apigee-cassandra-default 1/1 21m 
- Si el recuento de réplicas está configurado en 1, realiza los siguientes pasos para aumentarlo a un número mayor.
Solución
Las implementaciones híbridas de Apigee que no sean de producción pueden tener un recuento de réplicas de Cassandra establecido en 1. Si la alta disponibilidad de Cassandra es importante en implementaciones que no son de producción, aumenta el recuento de réplicas a 3 para resolver este problema.
Sigue estos pasos para intentar resolver el problema:
- Actualiza el archivo overrides.yamly establece el recuento de réplicas de Cassandra en 3:cassandra: replicaCount: 3 Para obtener información sobre la configuración de Cassandra, consulta la referencia de propiedades de configuración. 
- Aplica la configuración anterior con Helm:
      Prueba de validación: helm upgrade datastore apigee-datastore/ \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ -f OVERRIDES_FILE \ --dry-run Instala el gráfico de Helm helm upgrade datastore apigee-datastore/ \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ -f OVERRIDES_FILE 
- Obtén el conjunto con estado de Cassandra y verifica el recuento de réplicas actual:
kubectl -n get statefulsets -l app=apigee-cassandra Resultado de muestra: NAME READY AGE apigee-cassandra-default 3/3 27m 
- Obtén los pods de Cassandra y verifica el recuento de instancias actual. Si ningún pod está listo y todos están en el estado Running, espera a que se creen y activen los nuevos pods de Cassandra:kubectl -n get pods -l app=apigee-cassandra Resultado de muestra: 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 Resultado de muestra: 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 
Se debe recopilar información de diagnóstico
Si el problema persiste incluso después de seguir las instrucciones anteriores, recopila la siguiente información de diagnóstico y, luego, comunícate con Atención al cliente de Google Cloud.
- ID del proyecto de Google Cloud
- Organización de Apigee Hybrid/Apigee
- Para Apigee Hybrid: overrides.yaml, que enmascara información sensible
- Estado del Pod de Kubernetes en todos los espacios de nombres:
kubectl get pods -A > kubectl-pod-status`date +%Y.%m.%d_%H.%M.%S`.txt 
- Volcado de información del clúster de 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/* 
Referencias
- Escala Cassandra de forma horizontal
- Introspección y depuración de aplicaciones de Kubernetes
- Hoja de referencia de kubectl