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

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

Questo documento descrive come reimpostare i componenti di Apigee Hybrid quando sono bloccati nello 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 questo comando per visualizzare lo stato attuale:

kubectl get apigeedatastore -n NAMESPACE

Quando sono completamente funzionali, ciascuno di questi componenti si trova nello stato running. Ad esempio:

NAME      STATE     AGE
default   running   5d6h

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

NAME      STATE     AGE
default   creating   5d6h

Identificare il problema

Per identificare la causa del problema, inizia descrivendo ogni 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 stati 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. Esamina i log dei 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 ricrea l'ambiente utilizzando Helm:

kubectl delete -n apigee apigeeenv HASHED_ENV_NAME

Dopodiché, crea l'ambiente (dopo aver apportato le correzioni necessarie):

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

Assicurati di includere tutte le impostazioni mostrate, incluso --atomic in modo che l'azione venga annullata in caso di errore.

Installa il grafico:

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

Ispeziona il controller

Se nel pod non sono presenti messaggi di errore evidenti, ma il componente non è passato allo stato running, controlla apigee-controller per individuare eventuali messaggi di errore.

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

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

Datastore Apigee

Apache Cassandra è implementato come StatefulSet. Ogni istanza di 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, ma 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 (come le modifiche alla password di Cassandra) e problemi non correlati al networking potrebbero richiedere l'eliminazione dei componenti. È molto probabile che in questi casi non sia possibile eliminare l'istanza (ovvero kubectl delete apigeedatastore -n NAMESPACE default). L'utilizzo di --force o --grace-period=0 non è utile.

L'obiettivo di reset è modificare lo stato del componente (apigeedatastore) da creating o releasing a running. La modifica dello stato in questo modo in genere non risolve il problema di fondo. Nella maggior parte dei casi, il componente deve essere eliminato dopo un ripristino.

Avviso:l'eliminazione di apigeedatastore elimina anche i volumi permanenti. Tutti i dati in Cassandra andranno persi. Ti consigliamo di eseguire il backup dei dati di Cassandra.

Prova a eliminare (l'operazione non andrà a buon fine):
```
kubectl delete -n NAMESPACE apigeedatastore default
```
È normale che questo comando non venga completato. Utilizza Ctrl+C e termina la chiamata.

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 finalizzatore (finestra 2):

kubectl edit -n NAMESPACE apigeedatastore default

Cerca le seguenti due righe ed eliminale:

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

Scenari di errore comuni

Configurazione del proxy non disponibile con il runtime

Questo errore può manifestarsi in due modi:

runtime non è nello stato ready.
runtime non ha ricevuto l'ultima versione dell'API.

Inizia dai pod synchronizer.

Esamina i log per synchronizer. Gli errori comuni sono i seguenti:
- Mancanza di connettività di rete (a *.googleapi.com)
- Accesso IAM errato (account di servizio non disponibile o non fornito dall'autorizzazione di Synchronizer Manager)
- L'API setSyncAuthorization non è stata richiamata
Ispeziona 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 raggiunga il data plane. Nei casi in cui una convalida è impossibile o non implementata correttamente, runtime non riuscirà a caricarla.

"Nessun pod di runtime" nel control plane

Inizia dai pod synchronizer.

Ispeziona i log per synchronizer. Gli errori comuni sono i seguenti:
- Mancanza di connettività di rete (a *.googleapi.com)
- Accesso IAM errato (account di servizio non disponibile o non fornito dall'autorizzazione di Synchronizer Manager)
- L'API setSyncAuthorization non è stata richiamata. Forse la configurazione non è mai arrivata al piano dati.
Ispeziona i pod runtime.

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

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

La sessione di debug non viene visualizzata nel control plane

Inizia dai pod synchronizer.

Esamina i log per synchronizer. Gli errori comuni sono i seguenti:
- Mancanza di connettività di rete (a *.googleapi.com)
- Accesso IAM errato (account di servizio non disponibile o non fornito dall'autorizzazione di Synchronizer Manager)
- L'API setSyncAuthorization non è stata richiamata.
Ispeziona i pod runtime.
L'ispezione dei log dei pod runtime mostrerà perché runtime non invia log di debug a UDCA.
Ispeziona i pod UDCA.
L'ispezione dei log dell'agente UDCA mostrerà perché l'agente UDCA non invia informazioni sulla sessione di debug al control plane.

Cassandra restituisce risposte della cache di grandi dimensioni

Il seguente messaggio di avviso indica che Cassandra riceve richieste di lettura o scrittura con un payload più grande e può essere ignorato in sicurezza, in quanto questa soglia di avviso è impostata su un valore inferiore per indicare le dimensioni del payload di risposta.

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

Risoluzione dei problemi di Apigee hybrid bloccato nello stato di creazione o rilascio Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Identificare il problema

Eliminazione dei componenti

Ispeziona il controller

Datastore Apigee

Scenari di errore comuni

Configurazione del proxy non disponibile con il runtime

"Nessun pod di runtime" nel control plane

La sessione di debug non viene visualizzata nel control plane

Cassandra restituisce risposte della cache di grandi dimensioni

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