Las implementaciones de proxies de API fallan con una advertencia "Sin pods del entorno de ejecución activos"

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-runtime no 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

  1. 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
  2. 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

  1. 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.
  2. 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

  1. 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
  2. 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:

  1. Actualiza el archivo overrides.yaml y 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.

  2. Aplica la configuración anterior mediante la CLI de apigeectl:
    cd path/to/hybrid-files
    apigeectl apply -f overrides/overrides.yaml
  3. 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
  4. 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 Asistencia de Apigee.

  1. ID del proyecto de Google Cloud
  2. Organización de Apigee Hybrid/Apigee
  3. Para Apigee Hybrid: overrides.yaml, que enmascara información sensible
  4. 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
  5. 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