As implantações de proxy de API falham sem aviso ativo de pods do ambiente de execução

Esta é a documentação da Apigee e da Apigee híbrida.
Confira a documentação da Apigee Edge.

Sintomas

As implantações de proxies de API falham com o aviso Nenhum pod de ambiente de execução ativo na IU da Apigee híbrida.

Mensagens de erro

O aviso Nenhum cluster de ambiente de execução ativo é exibido na caixa de diálogo Detalhes ao lado da mensagem de erro Problemas de implantação em ENVIRONMENT: REVISION_NUMBER na página de proxy da API:

Esse problema pode se manifestar como erros diferentes em outras páginas de recursos da IU. Veja alguns exemplos de mensagens de erro:

Mensagem de erro da IU híbrida no 1: erro do Datastore

Observe o Erro do Datastore nas páginas Produtos de API e Apps da IU do híbrido, conforme mostrado abaixo:

Mensagem de erro da IU híbrida no 2: erro interno no servidor

Observe o Erro interno do servidor na página Desenvolvedores da IU, conforme mostrado abaixo:

Saída de comando do Kubectl

Você pode observar que os status dos pods apiege-mart, apigee-runtime e apigee- synchronizer estão sendo alterados para CrashLoopBackOff na saída do comando kubectl get pods:

Mensagens de erro do registro do componente

Você observará os seguintes erros de falha de sondagem de ativação nos registros do pod apigee-runtime nas versões do Apigee híbrido >= 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"}

Você observará o seguinte erro Cannot build a cluster without contact points nos registros de pod apigee-synchronizer em versões da Apigee híbrida > ou mais 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"}

Você observará os seguintes erros de falha de sondagem de ativação nos registros do pod apigee-mart nas versões da Apigee híbrida > 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"}

Informações sobre o erro "Nenhum pod de ambiente de execução ativo"

Na versão 1.4.0 da Apigee híbrida, o recurso de sondagem de ativação foi adicionado aos pods apigee-runtime e apigee-mart para verificar o status dos pods do Cassandra. Se todos os pods do Cassandra ficarem indisponíveis, as sondagens de atividade dos pods apigee-runtime e apigee-mart falharão. Assim, os pods apigee-runtime e apigee-mart entrarão no estado CrashLoopBackOff , causando falhas nas implantações de proxies de API com o aviso No active runtime pods. O pod apigee-synchronizer também passará para o estado CrashLoopBackOff devido à indisponibilidade dos pods do Cassandra.

Causas possíveis

Veja algumas possíveis causas para esse erro:

Causa Descrição
Os pods do Cassandra estão inativos Os pods do Cassandra estão inativos. Portanto, os pods apigee-runtime não poderão se comunicar com o banco de dados do Cassandra.
Réplica do Cassandra configurada com apenas um pod Ter apenas um pod do Cassandra pode se tornar um ponto único de falha.

Causa: os pods do Cassandra estão inativos

Durante o processo de implantação do proxy de API, os pods apigee-runtime se conectam ao banco de dados do Cassandra para buscar recursos, como mapas de chave-valor (KVMs) e caches, definidos no proxy de API. Se não houver pods do Cassandra em execução, os pods apigee-runtime não poderão se conectar ao banco de dados do Cassandra. Isso leva à falha da implantação do proxy de API.

Diagnóstico

  1. Liste os pods do Cassandra: 
    kubectl -n apigee get pods -l app=apigee-cassandra

    Exemplo de resposta 1:

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

    Exemplo de resposta 2:

    NAME                 READY   STATUS            RESTARTS   AGE
apigee-cassandra-0   0/1     CrashLoopBackoff  0          10m
  2. Verifique o status de cada pod do Cassandra. O status de todos os pods do Cassandra precisa estar no estado Running. Se algum dos pods do Cassandra estiver em um estado diferente, esse poderá ser o motivo do problema. Siga estas etapas para resolver o problema:

Resolução

  1. Se algum dos pods do Cassandra estiver no estado Pending, consulte Os pods do Cassandra estão presos no estado pendente para resolver o problema.
  2. Se algum dos pods do Cassandra estiver no estado CrashLoopBackoff, consulte Os pods do Cassandra estão presos no estado CrashLoopBackoff para resolver o problema.

    Exemplo de resposta:

    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: réplica do Cassandra configurada com apenas um pod

Se a contagem de réplicas do Cassandra estiver configurada para apenas um, haverá apenas um pod do Cassandra disponível no ambiente de execução. Como resultado, os pods apigee-runtime poderão ter problemas de conectividade se o pod do Cassandra ficar indisponível por um determinado período.

Diagnóstico

  1. Receba o conjunto com estado do Cassandra e verifique a contagem atual de réplicas: 
    kubectl -n apigee get statefulsets -l app=apigee-cassandra

    Exemplo de resposta:

    NAME                               READY           AGE
apigee-cassandra-default           1/1             21m
  2. Se a contagem de réplicas estiver configurada como 1, execute as etapas a seguir para aumentá-la para um número maior.

Resolução

As implantações de não produção híbridas da Apigee podem ter a contagem de réplicas do Cassandra definida como 1. Se a alta disponibilidade do Cassandra for importante em implantações que não sejam de produção, aumente a contagem de réplicas para três para resolver esse problema.

Siga estas etapas para tentar resolver esse problema:

  1. Atualize o arquivo overrides.yaml e defina a contagem de réplicas do Cassandra para 3: 
    cassandra:
  replicaCount: 3

    Para informações de configuração do Cassandra, consulte Referência da propriedade de configuração.

  2. Aplique a configuração acima usando a CLI apigeectl: 
    cd path/to/hybrid-files
apigeectl apply -f overrides/overrides.yaml
  3. Receba o conjunto com estado do Cassandra e verifique a contagem atual de réplicas: 
    kubectl -n get statefulsets -l app=apigee-cassandra

    Exemplo de resposta:

    NAME                              READY         AGE
apigee-cassandra-default          3/3           27m
  4. Consiga os pods do Cassandra e verifique a contagem atual de instâncias. Se todos os pods não estiverem prontos e no estado Running aguarde a criação e ativação dos novos pods do Cassandra: 
    kubectl -n get pods -l app=apigee-cassandra

    Exemplo de resposta:

    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

    Exemplo de resposta:

    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

É necessário coletar informações de diagnóstico

Se o problema persistir mesmo depois de seguir as instruções acima, reúna as seguintes informações de diagnóstico e entre em contato com o Suporte do Google Cloud:

  1. ID do projeto do Google Cloud
  2. Organização da Apigee híbrida/Apigee
  3. Para a Apigee híbrida: o overrides.yaml, mascarando informações confidenciais
  4. Status do pod do Kubernetes em todos os namespaces: 
    kubectl get pods -A > kubectl-pod-status`date +%Y.%m.%d_%H.%M.%S`.txt
  5. Dump de informações do cluster do 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/*

Referências