Solução de problemas da Apigee híbrida travada na criação ou liberação de estado

Esta é a documentação da Apigee e da Apigee híbrida.
Não há documentação equivalente do Apigee Edge para esse tópico.

Neste documento, descrevemos como redefinir os componentes da Apigee híbrida quando eles estão presos no estado creating ou releasing.

Execute o seguinte comando para listar os principais componentes de instalação da Apigee híbrida: 

kubectl get crd | grep apigee

apigeeorganization (apigeeorganizations.apigee.cloud.google.com)
apigeeenvironment (apigeeenvironments.apigee.cloud.google.com)
apigeedatastore (apigeedatastores.apigee.cloud.google.com)
apigeetelemetries (apigeetelemetries.apigee.cloud.google.com)
apigeeredis (apigeeredis.apigee.cloud.google.com)

Execute o comando a seguir para exibir o estado atual:

kubectl get apigeedatastore -n NAMESPACE

Quando totalmente funcional, cada um desses componentes estará no estado running. Exemplo: 

NAME      STATE     AGE
default   running   5d6h

Se a instalação não for bem-sucedida, os componentes poderão estar travados no estado creating (ou releasing). Exemplo: 

NAME      STATE     AGE
default   creating   5d6h

Identificar o problema

Para identificar a causa do problema, comece descrevendo cada componente. Os componentes são estruturados da seguinte maneira:

Cada recurso personalizado ApigeeOrganization é representado pela seguinte hierarquia: 

ApigeeOrganization/HASHED_VALUE
├─ApigeeDeployment/apigee-connect-agent-HASHED_VALUE
│ ├─HorizontalPodAutoscaler/apigee-connect-agent-HASHED_VALUE-VER-xxxx
│ ├─PodDisruptionBudget/apigee-connect-agent-HASHED_VALUE
│ ├─ReplicaSet/apigee-connect-agent-HASHED_VALUE-VER-xxxx
│ │ └─Pod/apigee-connect-agent-HASHED_VALUE-VER-xxxx
├─ApigeeDeployment/apigee-mart-HASHED_VALUE
│ ├─HorizontalPodAutoscaler/apigee-mart-HASHED_VALUE-VER-xxxx
│ ├─PodDisruptionBudget/apigee-mart-HASHED_VALUE
│ ├─ReplicaSet/apigee-mart-HASHED_VALUE-VER-xxxx
│ │ └─Pod/apigee-mart-HASHED_VALUE-VER-xxxx
├─ApigeeDeployment/apigee-watcher-HASHED_VALUE
│ ├─HorizontalPodAutoscaler/apigee-watcher-HASHED_VALUE-VER-xxxx
│ ├─PodDisruptionBudget/apigee-watcher-HASHED_VALUE
│ ├─ReplicaSet/apigee-watcher-HASHED_VALUE-VER-xxxx
│ │ └─Pod/apigee-watcher-HASHED_VALUE-VER-xxxx

Cada recurso personalizado ApigeeEnvironment é representado pela seguinte hierarquia: 

ApigeeEnvironment/HASHED_VALUE
├─ApigeeDeployment/apigee-runtime-HASHED_VALUE
│ ├─HorizontalPodAutoscaler/apigee-runtime-HASHED_VALUE-VER-xxxx
│ ├─PodDisruptionBudget/apigee-runtime-HASHED_VALUE
│ ├─ReplicaSet/apigee-runtime-HASHED_VALUE-VER-xxxx
│ │ └─Pod/apigee-runtime-HASHED_VALUE-VER-xxxx
├─ApigeeDeployment/apigee-synchronizer-HASHED_VALUE
│ ├─HorizontalPodAutoscaler/apigee-synchronizer-HASHED_VALUE-VER-xxxx
│ ├─PodDisruptionBudget/apigee-synchronizer-HASHED_VALUE
│ ├─ReplicaSet/apigee-synchronizer-HASHED_VALUE-VER-xxxx
│ │ └─Pod/apigee-synchronizer-HASHED_VALUE-VER-xxxx
├─ApigeeDeployment/apigee-udca-HASHED_VALUE
│ ├─HorizontalPodAutoscaler/apigee-udca-HASHED_VALUE-VER-xxxx
│ ├─PodDisruptionBudget/apigee-udca-HASHED_VALUE
│ ├─ReplicaSet/apigee-udca-HASHED_VALUE-VER-xxxx
│ │ └─Pod/apigee-udca-HASHED_VALUE-VER-xxxx

Comece a identificação do problema descrevendo o componente raiz. Exemplo:

kubectl describe apigeeorganization -n NAMESPACE COMPONENT_NAME

Verifique se o State do componente é running:

      Replicas:
        Available:  1
        Ready:      1
        Total:      1
        Updated:    1
      State:        running
  State:            running
Events:             <none>

Se não houver eventos registrados nesse nível, repita o processo com apigeedeployments seguido por ReplicaSet. Exemplo: 

kubectl get apigeedeployment -n NAMESPACE AD_NAME>

Se apigeedeployments e ReplicaSet não mostrarem erros, concentre-se nos pods que não estão prontos: 

kubectl get pods -n NAMESPACE

NAME                                                              READY   STATUS
apigee-cassandra-default-0                                        1/1     Running
apigee-connect-agent-apigee-b56a362-150rc2-42gax-dbrrn            1/1     Running
apigee-logger-apigee-telemetry-s48kb                              1/1     Running
apigee-mart-apigee-b56a362-150rc2-bcizm-7jv6w                     0/2     Running
apigee-runtime-apigee-test-0d59273-150rc2-a5mov-dfb29             0/1     Running

Neste exemplo, mart e runtime não estão prontos. Inspecione os registros do pod para determinar erros:

kubectl logs -n NAMESPACE POD_NAME

Como excluir componentes

Se você tiver cometido um erro com qualquer um desses componentes, basta excluí-lo e aplicar apigeectl a ele. Por exemplo, para excluir um ambiente: 

kubectl delete -n apigee apigeeenv HASHED_ENV_NAME

Faça o seguinte para criar o ambiente (depois de fazer as correções necessárias): 

apigeectl apply -f overrides.yaml –env=$ENV

Inspecionar o controlador

Se não houver mensagens de erro óbvias no pod, mas o componente não tiver feito a transição para o estado running, inspecione o apigee-controller em busca de mensagens de erro. O apigee-controller é executado no namespace apigee-system. 

kubectl logs -n apigee-system $(k get pods -n apigee-system | sed -n '2p' | awk '{print $1}') | grep -i error

Isso permite que o usuário veja por que o controlador não conseguiu processar a solicitação (de create/delete/update etc.).

Armazenamento de dados da Apigee

O Apache Cassandra é implementado como um StatefulSet. Cada instância do Cassandra contém: 

ApigeeDatastore/default
├─Certificate/apigee-cassandra-default
│ └─CertificateRequest/apigee-cassandra-default-wnd7s
├─Secret/config-cassandra-default
├─Service/apigee-cassandra-default
│ ├─EndpointSlice/apigee-cassandra-default-7m9kx
│ └─EndpointSlice/apigee-cassandra-default-gzqpr
└─StatefulSet/apigee-cassandra-default
  ├─ControllerRevision/apigee-cassandra-default-6976b77bd
  ├─ControllerRevision/apigee-cassandra-default-7fc76588cb
  └─Pod/apigee-cassandra-default-0

Este exemplo mostra um pod; No entanto, as instalações de produção típicas contêm três ou mais pods.

Se o estado do Cassandra for creating ou releasing, o estado PRECISA ser redefinido. Alguns problemas, como alterações de senha do Cassandra, e problemas não relacionados à rede podem exigir a exclusão de componentes. Nesses casos, é bem possível que não seja possível excluir a instância (ou seja, kubectl delete apigeedatastore -n NAMESPACE default. Usar --force ou --grace-period=0 também não ajuda.

O objetivo de reset é mudar o estado do componente (apigeedatastore) de creating ou releasing de volta para running. Alterar o estado dessa maneira normalmente não resolverá o problema subjacente. Na maioria dos casos, o componente deve ser excluído após uma redefinição.

  1. Tentar uma exclusão (isso não será bem-sucedido):

    kubectl delete -n NAMESPACE apigeedatastore default

    É comum que esse comando não seja concluído. Use Ctrl+C e encerre a chamada.

  2. Redefina o estado:

    Na janela 1:

    kubectl proxy

    Na janela 2:

    curl -X PATCH -H "Accept: application/json" -H "Content-Type: application/json-patch+json" --data '[{"op": "replace", "path": "/status/nestedState", "value": ""},{"op": "replace", "path": "/status/state", "value": "running"}]' 'http://127.0.0.1:8001/apis/apigee.cloud.google.com/v1alpha1/namespaces/apigee/apigeedatastores/default/status'

    Remova o finalizador (janela 2):

    kubectl edit -n NAMESPACE apigeedatastore default

    Procure e exclua as duas linhas a seguir:

    finalizers:
- apigeedatastore.apigee.cloud.google.com

Cenários comuns de erro

Configuração de proxy não disponível com o ambiente de execução

Esse erro pode se manifestar de duas maneiras:

  • O runtime não está no estado ready.
  • O runtime não recebeu a versão mais recente da API.

  1. Comece com os pods synchronizer.

    Inspecione os registros do synchronizer. Os erros comuns são os seguintes:

    • Falta de conectividade de rede (para *.googleapi.com)
    • Acesso incorreto do IAM (conta de serviço não disponível ou não fornecida pela permissão do Gerenciador de sincronização)
    • A API setSyncAuthorization não foi invocada

  2. Inspecione os pods runtime.

    Inspecionar os registros dos pods runtime mostrará por que o runtime não carregou a configuração. O plano de controle tenta impedir que a maioria dos erros de configuração vá até o plano de dados. Nos casos em que uma validação é impossível ou não é implementada corretamente, a runtime não a carrega.

"Nenhum pod de ambiente de execução" no plano de controle

  1. Comece com os pods synchronizer.

    Inspecione os registros do synchronizer. Os erros comuns são os seguintes:

    • Falta de conectividade de rede (para *.googleapi.com)
    • Acesso incorreto do IAM (conta de serviço não disponível ou não fornecida pela permissão do Gerenciador de sincronização)
    • A API setSyncAuthorization não foi invocada. Talvez a configuração nunca tenha passado pelo plano de dados.

  2. Inspecione os pods runtime.

    Inspecionar os registros dos pods runtime mostrará por que o runtime não carregou a configuração.

  3. Inspecione os pods watcher.

    É o componente watcher que configura a entrada (roteamento) e informa o status da implantação do proxy e da entrada para o plano de controle. Inspecione esses registros para descobrir por que o watcher não está informando o status. Os motivos mais comuns incluem uma incompatibilidade entre os nomes no arquivo overrides.yaml e no plano de controle para o nome do ambiente e/ou do nome do grupo de ambientes.

A sessão de depuração não está aparecendo no plano de controle

  1. Comece com os pods synchronizer.

    Inspecione os registros do synchronizer. Os erros comuns são os seguintes:

    • Falta de conectividade de rede (para *.googleapi.com)
    • Acesso incorreto do IAM (conta de serviço não disponível ou não fornecida pela permissão do Gerenciador de sincronização)
    • A API setSyncAuthorization não foi invocada.
  2. Inspecione os pods runtime.
    Inspecionar os registros dos pods runtime mostrará por que o runtime não está enviando registros de depuração para UDCA.
  3. Inspecione os pods do UDCA.
    A inspeção dos registros da UDCA mostrará por que a UDCA não está enviando informações de sessão de depuração para o plano de controle.

Cassandra retornando respostas em cache grandes

A mensagem de aviso a seguir indica que o Cassandra está recebendo solicitações de leitura ou gravação com um payload maior e pode ser ignorado com segurança, já que esse limite de aviso é definido como um valor mais baixo para indicar os tamanhos do payload da resposta.

Batch for [cache_ahg_gap_prod_hybrid.cache_map_keys_descriptor, cache_ahg_gap_prod_hybrid.cache_map_entry] is of size 79.465KiB, exceeding specified threshold of 50.000KiB by 29.465KiB