Stai visualizzando la documentazione relativa a Apigee e Apigee ibrido.
Non esiste una equivalente
Documentazione di Apigee Edge per questo argomento.
Questo documento descrive come reimpostare i componenti ibridi di Apigee quando rimangono bloccati in una
Stato creating
o releasing
.
Esegui questo comando per elencare i componenti principali dell'installazione ibrida di Apigee:
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
Una volta completamente funzionante, ciascuno di questi componenti sarà nello stato running
.
Ad esempio:
NAME STATE AGE default running 5d6h
Se l'installazione non va a buon fine, i componenti potrebbero essere bloccati in un 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 di 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 di 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
Verifica se il State
del componente è running
:
Replicas:
Available: 1
Ready: 1
Total: 1
Updated: 1
State: running
State: running
Events: <none>
Se non ci sono eventi registrati a questo livello, ripeti il processo con
apigeedeployments
seguito da ReplicaSet
. Ad esempio:
kubectl get apigeedeployment -n NAMESPACE AD_NAME>
Se apigeedeployments
e ReplicaSet
non mostrano errori, imposta lo stato attivo
sui pod che non sono 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-7jv6w0
/2 Running apigee-runtime-apigee-test-0d59273-150rc2-a5mov-dfb290
/1 Running
In questo esempio, mart
e runtime
non sono pronti. Controlla 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 applica
apigeectl
per quel componente. Ad esempio, per eliminare un ambiente:
kubectl delete -n apigee apigeeenv HASHED_ENV_NAME
Prosegui con la creazione dell'ambiente (dopo aver apportato le correzioni necessarie):
apigeectl apply -f overrides.yaml –env=$ENV
Ispeziona il controller
Se non sono presenti messaggi di errore evidenti nel pod, ma il componente non è stato trasferito al pod
running
; controlla se in apigee-controller
sono presenti messaggi di errore. La
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
Consente all'utente di vedere 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; tuttavia, le tipiche installazioni di produzione contengono tre o più pod.
Se lo stato per Cassandra è creating
o releasing
, lo stato DEVE essere
resettare. Alcuni problemi (come le modifiche delle password di Cassandra) e problemi non correlati al networking
potrebbe richiedere l'eliminazione di alcuni componenti. È del tutto possibile che in questi casi non sia possibile eliminare
sull'istanza (ad es. kubectl delete apigeedatastore -n NAMESPACE default
). Utilizzo
Anche --force
o --grace-period=0
non aiutano.
L'obiettivo di reset
è modificare lo stato del componente
(apigeedatastore
) da creating
o releasing
tornando a
running
. La modifica dello stato in questo modo in genere non risolve il problema
problema di base. Nella maggior parte dei casi, il componente dovrebbe essere eliminato dopo un ripristino.
Prova a eseguire l'eliminazione (l'operazione non avrà esito positivo):
kubectl delete -n NAMESPACE apigeedatastore default
Capita spesso che questo comando non venga completato. Utilizza Ctrl+C e interrompi 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 due righe seguenti ed eliminale:
finalizers: - apigeedatastore.apigee.cloud.google.com
Scenari di errore comuni
Configurazione proxy non disponibile con il runtime
Questo errore può manifestarsi in due modi:
runtime
non è nello statoready
.runtime
non ha ricevuto la versione più recente dell'API.
Inizia con i pod
synchronizer
.Controlla i log per
synchronizer
. Gli errori più comuni sono i seguenti:- Mancanza di connettività di rete (per
*.googleapi.com
) - Accesso IAM errato (account di servizio non disponibile o non fornito dal autorizzazione Gestore sincronizzato)
- Lo L'API setSyncAuthorization non è stata richiamata
- Mancanza di connettività di rete (per
Esamina i pod
runtime
.L'ispezione dei log dai pod
runtime
mostrerà perchéruntime
non ha caricato la configurazione. Il piano di controllo tenta di impedire per la maggior parte degli errori di configurazione, arrivando anche al piano dati. Nei casi in cui la convalida sia impossibile o non implementato correttamente, il caricamento diruntime
non andrà a buon fine li annotino.
"Nessun pod di runtime" nel piano di controllo
Inizia con i pod
synchronizer
.Controlla i log per
synchronizer
. Gli errori più comuni sono i seguenti:- Mancanza di connettività di rete (per
*.googleapi.com
) - Accesso IAM errato (account di servizio non disponibile o non fornito dal autorizzazione Gestore sincronizzato)
- Lo L'API setSyncAuthorization non è stata richiamata. Forse la configurazione non è mai riuscita al piano dati.
- Mancanza di connettività di rete (per
Esamina i pod
runtime
.L'ispezione dei log dal I pod
runtime
mostreranno perchéruntime
non ha caricato configurazione.Esamina i pod
watcher
.È il componente
watcher
che configura il traffico in entrata (routing) e i report del proxy e dello stato di deployment in entrata nel piano di controllo. Esamina questi log per scoprire perchéwatcher
non segnala lo stato. Le cause comuni includono una mancata corrispondenza tra i nomi nel fileoverrides.yaml
e il piano di controllo il nome ambiente e/o il nome del gruppo di ambienti.
La sessione di debug non viene visualizzata nel piano di controllo
Inizia con i pod
synchronizer
.Controlla i log per
synchronizer
. Gli errori più comuni sono i seguenti:- Mancanza di connettività di rete (per
*.googleapi.com
) - Accesso IAM errato (account di servizio non disponibile o non fornito dal autorizzazione Gestore sincronizzato)
- Lo L'API setSyncAuthorization non è stata richiamata.
- Mancanza di connettività di rete (per
- Esamina i pod
runtime
.
Ispezione dei log daruntime
i pod mostreranno perchéruntime
non invia i log di debug all'UDCA. - Esamina i pod UDCA.
L'ispezione dei log della UDCA consente di capire perché non invio delle informazioni sulla sessione di debug al piano di controllo.
Cassandra che restituisce risposte della cache di grandi dimensioni
Il seguente messaggio di avviso indica che Cassandra sta ricevendo richieste di lettura o scrittura con un di maggiori dimensioni e può essere tranquillamente ignorata poiché questa soglia di avviso è impostata su un valore più basso indicano le dimensioni dei 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