Risoluzione dei problemi relativi ad Apigee hybrid bloccato nello stato di creazione o rilascio

Stai visualizzando la documentazione di Apigee e Apigee hybrid.
Non esiste documentazione equivalente di Apigee Edge per questo argomento.

Questo documento descrive come reimpostare i componenti ibrida di Apigee quando sono bloccati in uno stato creating o releasing.

Esegui il seguente comando per elencare i componenti principali dell'installazione di 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)

Esegui il seguente comando per visualizzare lo stato corrente:

kubectl get apigeedatastore -n NAMESPACE

Quando sono completamente funzionali, ciascuno di questi componenti sarà in uno stato running. Ad esempio: 

NAME      STATE     AGE
default   running   5d6h

Se l'installazione non va a buon fine, i componenti potrebbero rimanere bloccati in uno stato creating (o releasing). Ad esempio: 

NAME      STATE     AGE
default   creating   5d6h

Identificare il problema

Per identificare la causa del problema, inizia descrivendo ciascun componente. I componenti sono strutturati come segue:

Ogni risorsa personalizzata ApigeeOrganization è rappresentata dalla seguente gerarchia: 

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

Ogni risorsa personalizzata ApigeeEnvironment è rappresentata dalla seguente gerarchia: 

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

Inizia l'identificazione del problema descrivendo il componente principale. Ad esempio:

kubectl describe apigeeorganization -n NAMESPACE COMPONENT_NAME

Controlla se il State del componente è running:

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

Se non sono registrati eventi a questo livello, ripeti la procedura con apigeedeployments seguito da ReplicaSet. Ad esempio: 

kubectl get apigeedeployment -n NAMESPACE AD_NAME>

Se apigeedeployments e ReplicaSet non mostrano errori, concentrati sui pod non pronti: 

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

In questo esempio, mart e runtime non sono pronti. Controlla i log del pod per determinare gli errori:

kubectl logs -n NAMESPACE POD_NAME

Eliminazione dei componenti

Se hai commesso un errore con uno di questi componenti, eliminalo e applica apigeectl per quel componente. Ad esempio, per eliminare un ambiente: 

kubectl delete -n apigee apigeeenv HASHED_ENV_NAME

Dopo aver apportato le correzioni necessarie, crea l'ambiente: 

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

Ispeziona il controller

Se non sono presenti messaggi di errore evidenti nel pod, ma il componente non è passato allo stato running, controlla se sono presenti messaggi di errore in apigee-controller. apigee-controller viene eseguito nello spazio dei nomi apigee-system. 

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

In questo modo l'utente può capire perché il controller non è stato in grado di elaborare la richiesta (di create/delete/update e così via).

Datastore Apigee

Apache Cassandra è implementato come StatefulSet. Ogni istanza Cassandra contiene: 

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

Questo esempio mostra un pod; tuttavia, le installazioni di produzione tipiche contengono tre o più pod.

Se lo stato di Cassandra è creating o releasing, lo stato DEVE essere reimpostato. Alcuni problemi (ad esempio le modifiche della password di Cassandra) e problemi non correlati alla rete potrebbero richiedere l'eliminazione di componenti. È possibile che in questi casi non sia possibile eliminare l'istanza (ad es. kubectl delete apigeedatastore -n NAMESPACE default). Anche l'utilizzo di --force o --grace-period=0 non è utile.

Lo scopo di reset è cambiare lo stato del componente (apigeedatastore) da creating o releasing a running. In genere, la modifica dello stato in questo modo non risolve il problema di fondo. Nella maggior parte dei casi, il componente deve essere eliminato dopo un ripristino dei dati di fabbrica.

  1. Prova a eliminare l'elemento (l'operazione non andrà a buon fine):

    kubectl delete -n NAMESPACE apigeedatastore default

    È normale che questo comando non venga completato. Usa Ctrl+C e termina la chiamata.

  2. Reimposta lo stato:

    Nella finestra 1:

    kubectl proxy

    Nella finestra 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'

    Rimuovi il perfezionatore (finestra 2):

    kubectl edit -n NAMESPACE apigeedatastore default

    Cerca le due righe seguenti ed eliminale:

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

Scenari di errori comuni

Configurazione del proxy non disponibile con il runtime

Questo errore può manifestarsi in due modi:

  • runtime non è nello stato ready.
  • Il runtime non ha ricevuto la versione più recente dell'API.

  1. Inizia con i synchronizer pod.

    Esamina i log per synchronizer. Gli errori comuni sono i seguenti:

    • Mancata connettività di rete (a *.googleapi.com)
    • Accesso IAM errato (account di servizio non disponibile o non fornito dall'autorizzazione Gestore sincronizzatore)
    • L'API setSyncAuthorization non è stata invocata

  2. Controlla i pod runtime.

    L'ispezione dei log dei pod runtime mostrerà perché runtime non ha caricato la configurazione. Il control plane tenta di impedire che la maggior parte degli errori di configurazione venga visualizzata nel data plane. Nei casi in cui una convalida sia impossibile o non sia stata implementata correttamente, il runtime non riuscirà a caricarla.

"Nessun pod di runtime" nel piano di controllo

  1. Inizia con i synchronizer pod.

    Esamina i log per synchronizer. Gli errori comuni sono i seguenti:

    • Mancata connettività di rete (a *.googleapi.com)
    • Accesso IAM errato (account di servizio non disponibile o non fornito dall'autorizzazione Gestore sincronizzatore)
    • L'API setSyncAuthorization non è stata invocata. È possibile che la configurazione non sia mai stata eseguita nel piano dati.

  2. Controlla i pod runtime.

    L'ispezione dei log dei pod runtime mostrerà perché runtime non ha caricato la configurazione.

  3. Controlla i pod watcher.

    È il componente watcher che configura l'ingresso (routing) e segnala lo stato di implementazione del proxy e dell'ingresso al piano di controllo. Esamina questi log per scoprire perché il watcher non sta segnalando lo stato. I motivi più comuni includono una mancata corrispondenza tra i nomi nel file overrides.yaml e nel piano di controllo per il nome dell'ambiente e/o del gruppo di ambienti.

La sessione di debug non viene visualizzata nel piano di controllo

  1. Inizia con i synchronizer pod.

    Esamina i log per synchronizer. Gli errori comuni sono i seguenti:

    • Mancata connettività di rete (a *.googleapi.com)
    • Accesso IAM errato (account di servizio non disponibile o non fornito dall'autorizzazione Gestore sincronizzatore)
    • L'API setSyncAuthorization non è stata invocata.
  2. Controlla i pod runtime.
    L'ispezione dei log dei pod runtime mostrerà perché runtime non invia log di debug a UDCA.
  3. Controlla i pod UDCA.
    L'ispezione dei log dell'UDCA mostrerà perché l'UDCA non invia informazioni sulla sessione di debug al piano di controllo.

Cassandra restituisce risposte della cache di grandi dimensioni

Il seguente messaggio di avviso indica che Cassandra sta ricevendo richieste di lettura o scrittura con un payload più grande e può essere ignorato in tutta sicurezza poiché questa soglia di avviso è impostata su un valore inferiore per indicarne le dimensioni.

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