Resolução de problemas do Apigee Hybrid bloqueado no estado de criação ou lançamento

Está a ver a documentação do Apigee e do Apigee Hybrid.
Não existe nenhum equivalente Documentação do Apigee Edge para este tópico.

Este documento descreve como repor os componentes híbridos do Apigee quando estão bloqueados num estado creating ou releasing.

Execute o seguinte comando para listar os principais componentes da instalação do Apigee Hybrid: 

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 seguinte comando para apresentar o estado atual:

kubectl get apigeedatastore -n NAMESPACE

Quando estiverem totalmente funcionais, cada um destes componentes vai estar num estado running. Por exemplo: 

NAME      STATE     AGE
default   running   5d6h

Se a instalação não for bem-sucedida, os componentes podem ficar bloqueados num estado creating (ou releasing). Por exemplo: 

NAME      STATE     AGE
default   creating   5d6h

Identifique o problema

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

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 principal. Por 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 existirem eventos registados a este nível, repita o processo com apigeedeployments seguido de ReplicaSet. Por exemplo: 

kubectl get apigeedeployment -n NAMESPACE AD_NAME>

Se apigeedeployments e ReplicaSet não apresentarem 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 registos do pod para determinar os erros:

kubectl logs -n NAMESPACE POD_NAME

Eliminar componentes

Se cometeu um erro com algum destes componentes, elimine o componente e recrie o ambiente com o Helm: 

kubectl delete -n apigee apigeeenv HASHED_ENV_NAME

Em seguida, crie o ambiente (depois de fazer as correções necessárias): 

helm upgrade ENV_NAME apigee-env/ \
--install \
--namespace APIGEE_NAMESPACE \
--set env=ENV_NAME \
--atomic \
-f OVERRIDES_FILE \
--dry-run=server

Certifique-se de que inclui todas as definições apresentadas, incluindo --atomic para que a ação seja revertida em caso de falha.

Instale o gráfico:

helm upgrade ENV_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  --atomic \
  -f OVERRIDES_FILE

Inspecione o comando

Se não existirem mensagens de erro óbvias no grupo, mas o componente não tiver transitado para o estado running, inspecione o apigee-controller para ver se existem mensagens de erro. 

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

Isto permite que o utilizador veja o motivo pelo qual o controlador não conseguiu processar o pedido (de create/delete/update, etc.).

Armazenamento de dados do 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 agrupamento. No entanto, as instalações de produção típicas contêm três ou mais agrupamentos.

Se o estado do Cassandra for creating ou releasing, o estado TEM de ser reposto. Determinados problemas (como alterações à palavra-passe do Cassandra) e problemas não relacionados com redes podem exigir que elimine componentes. É bastante possível que, nesses casos, não consiga eliminar a instância (ou seja, kubectl delete apigeedatastore -n NAMESPACE default). A utilização de --force ou --grace-period=0 também não ajuda.

O objetivo de reset é alterar o estado do componente (apigeedatastore) de creating ou releasing para running. A alteração do estado desta forma não resolve normalmente o problema subjacente. Na maioria dos casos, o componente deve ser eliminado após uma reposição.

  1. Tentar eliminar (esta ação não vai ter êxito):

    kubectl delete -n NAMESPACE apigeedatastore default

    É comum este comando não ser concluído. Use Ctrl+C e termine a chamada.

  2. Reponha o estado:

    Na janela 1:

    kubectl proxy

    No período 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 as duas linhas seguintes e elimine-as:

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

Cenários de erro comuns

A configuração do proxy não está disponível com o tempo de execução

Este erro pode manifestar-se de duas formas:

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

  1. Comece com os synchronizerpods.

    Inspeccione os registos do synchronizer. Os erros comuns são os seguintes:

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

  2. Inspecione os runtime pods.

    A inspeção dos registos dos pods runtime mostra o motivo pelo qual o runtime não carregou a configuração. O plano de controlo tenta impedir que a maioria dos erros de configuração chegue ao plano de dados. Nos casos em que uma validação é impossível ou não é implementada corretamente, o runtime não a carrega.

"No runtime pods" no plano de controlo

  1. Comece com os synchronizerpods.

    Inspeccione os registos para o synchronizer. Os erros comuns são os seguintes:

    • Falta de conetividade de rede (para *.googleapi.com)
    • Acesso IAM incorreto (conta de serviço não disponível ou não fornecida pela autorização do gestor do sincronizador)
    • A API setSyncAuthorization não foi invocada. Talvez a configuração nunca tenha chegado ao plano de dados.

  2. Inspecione os runtime pods.

    A inspeção dos registos dos pods runtime mostra o motivo pelo qual o runtime não carregou a configuração.

  3. Inspecione os watcher pods.

    É o componente watcher que configura a entrada (encaminhamento) e comunica o estado de implementação do proxy e da entrada ao plano de controlo. Inspecione estes registos para saber por que motivo o watcher não está a comunicar o estado. Os motivos comuns incluem uma incompatibilidade entre os nomes no ficheiro overrides.yaml e o plano de controlo para o nome do ambiente e/ou o nome do grupo de ambientes.

A sessão de depuração não aparece no plano de controlo

  1. Comece com os synchronizerpods.

    Inspeccione os registos do synchronizer. Os erros comuns são os seguintes:

    • Falta de conetividade de rede (para *.googleapi.com)
    • Acesso IAM incorreto (conta de serviço não disponível ou não fornecida pela autorização do gestor do sincronizador)
    • A API setSyncAuthorization não foi invocada.
  2. Inspecione os runtime pods.
    A inspeção dos registos dos pods runtime mostra o motivo pelo qual o runtime não está a enviar registos de depuração para o UDCA.
  3. Inspecione os pods UDCA.
    A inspeção dos registos do UDCA mostra o motivo pelo qual o UDCA não está a enviar informações da sessão de depuração para o plano de controlo.

O Cassandra devolve respostas de cache grandes

A seguinte mensagem de aviso indica que o Cassandra está a receber pedidos de leitura ou escrita com uma carga útil maior e pode ser ignorada com segurança, uma vez que este limite de aviso está definido para um valor inferior para indicar os tamanhos da carga útil de 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