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.

Observação: este documento é destinado apenas a usuários da Apigee.

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.

Aviso: a exclusão de apigeedatastore também exclui os volumes permanentes. Todos os dados no Cassandra serão perdidos. É recomendável fazer backup dos dados do Cassandra.

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