Stai visualizzando la documentazione relativa a Apigee e Apigee ibrido.
Non esiste una equivalente
Documentazione di Apigee Edge per questo argomento.
In questo argomento vengono illustrati i passaggi che puoi svolgere per risolvere i problemi relativi all'
Datastore Cassandra. Cassandra è un
datastore permanente
in esecuzione nel componente cassandra
dell'
architettura di runtime ibrida.
Vedi anche
Panoramica della configurazione del servizio di runtime.
I pod Cassandra sono bloccati nello stato di rilascio
Sintomo
Dopo aver tentato di aggiornare i pod Cassandra, il datastore viene segnalando che è bloccato nello stato di rilascio.
Messaggio di errore
Quando usi kubectl
per visualizzare gli stati dei pod, ne viene visualizzato uno
o più pod Cassandra sono bloccati nello stato di rilascio:
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Ack 57s (x7 over 24h) apigee-datastore release started
Cause possibili
Un pod bloccato in stato di rilascio può essere causato da quanto segue:
Causa | Descrizione |
---|---|
Modifiche alla capacità di archiviazione |
Sono stati eseguiti dei passaggi per modificare la capacità di archiviazione
override.yaml .
|
Altre modifiche alla configurazione |
Sono stati apportati aggiornamenti alle proprietà Cassandra in
override.yaml file; ma le modifiche non sono state
effetto.
|
Modifiche alla capacità di archiviazione
Diagnosi
-
Usa
kubectl
per visualizzare lo stato attuale diapigee
pod datastore:kubectl get apigeeds -n apigee
NAME STATE AGE default releasing 122d
-
Controlla se sono state apportate modifiche al
override.yaml
file: -
Utilizzando il tuo sistema di controllo della versione, confronta la versione precedente
override.yaml
file con la versione corrente:diff OVERRIDES_BEFORE.yaml OVERRIDES_AFTER.yaml
-
L'output di una diff in
override.yaml
potrebbe mostrare un possibile problema con le dimensioni della capacità dello spazio di archiviazione. Ad esempio:# Overrides.yaml before: cassandra: storage: capacity: 500Gi # Overrides.yaml after: cassandra: storage: capacity: 100Gi
Se si fosse verificata un'operazione modificare la capacità di archiviazione per cui i passaggi sono stati saltati e viene
override.yaml
è stato applicato direttamente. Ciò può causare in stato di rilascio. -
Controlla
statefulset
per assicurarti che sia presente perapigee-cassandra-default
:kubectl describe sts -n apigee
L'output avrà un aspetto simile al seguente:
Name: apigee-cassandra-default Namespace: apigee CreationTimestamp: Tue, 18 Jul 2023 00:40:57 +0000 Selector: app=apigee-cassandra,name=default Labels: apigee.cloud.google.com.revision=v1-2cc098050836c6b4 apigee.cloud.google.com.version=v1 apigee.cloud.google.com/platform=apigee app=apigee-cassandra name=default Annotations: <none> Replicas: 3 desired | 3 total Update Strategy: RollingUpdate Partition: 0 Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed Pod Template: Labels: apigee.cloud.google.com/apigee_servicename=production apigee.cloud.google.com/billing_type=subscription apigee.cloud.google.com/platform=apigee app=apigee-cassandra name=default revision=v1 runtime_type=hybrid Annotations: apigee.cloud.google.com/pod-template-spec-hash: 2cc098050836c6b4 prometheus.io/path: /metrics prometheus.io/port: 7070 prometheus.io/scheme: https prometheus.io/scrape: true Containers: apigee-cassandra: Image: gcr.io/apigee-release/hybrid/apigee-hybrid-cassandra:1.10.1 Ports: 7000/TCP, 7001/TCP, 7199/TCP, 9042/TCP, 8778/TCP Host Ports: 7000/TCP, 7001/TCP, 7199/TCP, 9042/TCP, 8778/TCP Requests: cpu: 500m memory: 1Gi Readiness: exec [/bin/bash -c /opt/apigee/ready-probe.sh] delay=0s timeout=5s period=10s #success=1 #failure=2 Environment: POD_NAME: (v1:metadata.name) POD_IP: (v1:status.podIP) MAX_HEAP_SIZE: 512M HEAP_NEWSIZE: 100M CASSANDRA_SEEDS: apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local CASSANDRA_CLUSTER_NAME: apigeecluster CASSANDRA_DC: dc-1 CASSANDRA_RACK: ra-1 CASSANDRA_OPEN_JMX: true CPS_ADMIN_USER: <set to the key 'admin.user' in secret 'apigee-datastore-default-creds'> Optional: false CPS_ADMIN_PASSWORD: <set to the key 'admin.password' in secret 'apigee-datastore-default-creds'> Optional: false APIGEE_JMX_USER: <set to the key 'jmx.user' in secret 'apigee-datastore-default-creds'> Optional: false APIGEE_JMX_PASSWORD: <set to the key 'jmx.password' in secret 'apigee-datastore-default-creds'> Optional: false CASS_PASSWORD: <set to the key 'default.password' in secret 'apigee-datastore-default-creds'> Optional: false APIGEE_JOLOKIA_USER: <set to the key 'jolokia.user' in secret 'apigee-datastore-default-creds'> Optional: false APIGEE_JOLOKIA_PASSWORD: <set to the key 'jolokia.password' in secret 'apigee-datastore-default-creds'> Optional: false Mounts: /opt/apigee/apigee-cassandra/conf from appsfs (rw) /opt/apigee/customer from cwc-volume (ro) /opt/apigee/data from cassandra-data (rw) /opt/apigee/ssl from tls-volume (ro) /var/secrets/google from apigee-cassandra-backup (rw) /var/secrets/keys from apigee-cassandra-backup-key-file (rw) Volumes: cwc-volume: Type: Secret (a volume populated by a Secret) SecretName: config-cassandra-default Optional: false tls-volume: Type: Secret (a volume populated by a Secret) SecretName: apigee-cassandra-default-tls Optional: false appsfs: Type: EmptyDir (a temporary directory that shares a pod's lifetime) Medium: SizeLimit: <unset> apigee-cassandra-backup: Type: Secret (a volume populated by a Secret) SecretName: apigee-cassandra-backup-svc-account Optional: true apigee-cassandra-backup-key-file: Type: Secret (a volume populated by a Secret) SecretName: apigee-cassandra-backup-key-file Optional: true Volume Claims: Name: cassandra-data StorageClass: Labels: <none> Annotations: <none> Capacity: 10Gi Access Modes: [ReadWriteOnce] Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuccessfulCreate 47m statefulset-controller create Pod apigee-cassandra-default-2 in StatefulSet apigee-cassandra-default successful
-
Verifica la presenza di errori nel controller apigee:
kubectl logs -f apigee-controller-manager-59cf595c77-wtwnr -n apigee-system -c manager | grep apigeedatastore
Risultati:
"error creating apigee-cassandra object: failed to update resource apigee/apigee-cassandra-default: StatefulSet.apps \"apigee-cassandra-default\" is invalid: spec: Forbidden: updates to statefulset spec for fields other than 'replicas', 'template', 'updateStrategy', 'persistentVolumeClaimRetentionPolicy' and 'minReadySeconds' are forbiddenerror creating apigee-cassandra object: failed to update resource apigee/apigee-cassandra-default: StatefulSet.apps \"apigee-cassandra-default\" is invalid: spec: Forbidden: updates to statefulset spec for fields other than 'replicas', 'template', 'updateStrategy', 'persistentVolumeClaimRetentionPolicy' and 'minReadySeconds' are forbidden"
Risoluzione
Per ottenerlo, lo stato di Cassandra può essere reimpostato seguendo questi passaggi torna allo stato di esecuzione:
-
Disattiva
apigee-controller
:kubectl -n apigee-system edit deployments and set --enable-controllers=true to --enable-controllers=false
-
Ripristina lo stato di esecuzione del datastore utilizzando il comando
PATCH
:curl -XPATCH \-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'
-
Riapplica il file
override.yaml
originale:./apigeectl apply --datastore -f overrides.yaml
-
Attiva
apigee-controller
:kubectl -n apigee-system edit deployments and set --enable-controllers=false to --enable-controllers=true
-
Attendi il ripristino del datastore ed esegui la convalida utilizzando quanto segue:
kubectl get apigeeds --namespace apigee
-
Verificare che i deployment e i pod Apigee siano in esecuzione e
apigeeds
non è più in stato di rilascio:kubectl get ad -n apigee
kubectl get pods -n apigee
kubectl get apigeeds -n apigee
NAME STATE AGE default running 24d
Altre modifiche alla configurazione
Aggiornamenti apportati a cassandra
proprietà in
override.yaml
e le modifiche non sono state applicate. Potrebbe trattarsi di un
modifica della password o delle risorse in override.yaml
.
Oppure l'applicazione errata di override.yaml
a un cluster.
Diagnosi
Vedi la procedura descritta in Diagnosi.
Risoluzione
Consulta la procedura descritta in Risoluzione.
Raccogliere dati diagnostici
Se il problema persiste anche dopo aver seguito le istruzioni riportate sopra, raccogli riporta le seguenti informazioni diagnostiche e contatta l'assistenza clienti Google Cloud:
-
Overrides.yaml
per ogni cluster nell'installazione. -
Un dump delle informazioni del cluster Kubernetes dall'installazione ibrida:
Genera Kubernetes
cluster-info dump
:kubectl cluster-info dump -A --output-directory=/tmp/kubectl-cluster-info-dump
Comprimi con Kubernetes
cluster-info dump
:zip -r kubectl-cluster-info-dump`date +%Y.%m.%d_%H.%M.%S`.zip /tmp/kubectl-cluster-info-dump/*
I pod Cassandra sono bloccati nello stato In attesa
Sintomo
All'avvio, i pod Cassandra rimangono in stato In attesa.
Messaggio di errore
Quando utilizzi kubectl
per visualizzare gli stati dei pod, vedi che uno o più
I pod Cassandra sono bloccati nello stato Pending
. La
Lo stato Pending
indica che Kubernetes non è in grado di pianificare il pod
su un nodo: non è possibile creare il pod. Ad esempio:
kubectl get pods -n NAMESPACE
NAME READY STATUS RESTARTS AGE
adah-resources-install-4762w 0/4 Completed 0 10m
apigee-cassandra-default-0 0/1 Pending 0 10m
...
Cause possibili
Un pod bloccato nello stato In attesa può avere diverse cause. Ad esempio:
Causa | Descrizione |
---|---|
Risorse insufficienti | La CPU o la memoria disponibili non sono sufficienti per creare il pod. |
Volume non creato | Il pod è in attesa della creazione del volume permanente. |
Driver CSI Amazon EBS mancante | Per le installazioni EKS, il driver Amazon EBS CSI richiesto non è installato. |
Diagnosi
Usa kubectl
per descrivere il pod per determinare l'origine dell'errore. Ad esempio:
kubectl -n NAMESPACE describe pods POD_NAME
Ad esempio:
kubectl describe pods apigee-cassandra-default-0 -n apigee
L'output potrebbe mostrare uno di questi possibili problemi:
- Se il problema è costituito da risorse insufficienti, verrà visualizzato un messaggio di avviso che indica CPU o memoria insufficiente.
- Se il messaggio di errore indica che il pod ha oggetti PersistentVolumeClaim (PVC) immediati non associati, significa che il pod non è in grado di creare i suoi Volume permanente.
Risoluzione
Risorse insufficienti
Modifica il pool di nodi Cassandra in modo che disponga di risorse di CPU e memoria sufficienti. Vedi Ridimensionamento di un pool di nodi per maggiori dettagli.
Volume permanente non creato
Se rilevi un problema di volume permanente, descrivi l'oggetto PersistentVolumeClaim (PVC) per determinare perché non viene creato:
- Elenca le PVC nel cluster:
kubectl -n NAMESPACE get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE cassandra-data-apigee-cassandra-default-0 Bound pvc-b247faae-0a2b-11ea-867b-42010a80006e 10Gi RWO standard 15m ...
- Descrivi la PVC del pod che presenta errori. Ad esempio, il seguente comando
descrive la PVC associata al pod
apigee-cassandra-default-0
:kubectl apigee describe pvc cassandra-data-apigee-cassandra-default-0 Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning ProvisioningFailed 3m (x143 over 5h) persistentvolume-controller storageclass.storage.k8s.io "apigee-sc" not found
Tieni presente che in questo esempio non esiste un oggetto StorageClass denominato
apigee-sc
. A risolvere il problema, creare l'oggetto StorageClass mancante nel cluster, come spiegato in Modificare il valore predefinito del valore di StorageClass.
Vedi anche di debug dei pod.
Driver CSI Amazon EBS mancante
Se l'istanza ibrida è in esecuzione su un cluster EKS, assicurati che quest'ultimo utilizzi Driver Amazon EBS Container Storage Interface (CSI). Vedi Domande frequenti sulla migrazione ad Amazon EBS CSI per informazioni dettagliate.
I pod Cassandra sono bloccati nello stato CrashLoopBackoff
Sintomo
All'avvio, i pod Cassandra rimangono in stato CrashLoopBackoff.
Messaggio di errore
Quando utilizzi kubectl
per visualizzare gli stati dei pod, vedi che uno o più
I pod Cassandra sono in stato CrashLoopBackoff
.
Questo stato indica che Kubernetes non è in grado di creare il pod. Ad esempio:
kubectl get pods -n NAMESPACE
NAME READY STATUS RESTARTS AGE
adah-resources-install-4762w 0/4 Completed 0 10m
apigee-cassandra-default-0 0/1 CrashLoopBackoff 0 10m
...
Cause possibili
Un pod bloccato nello stato CrashLoopBackoff
può avere diverse cause. Ad esempio:
Causa | Descrizione |
---|---|
Il data center è diverso da quello precedente | Questo errore indica che il pod Cassandra ha un volume permanente con dati di una e i nuovi pod non potranno unirsi al cluster precedente. Questo di solito si verifica quando volumi permanenti inattivi rimangono dalla precedente versione di Cassandra di un cluster Kubernetes sullo stesso nodo Kubernetes. Questo problema può verificarsi se elimini e ricrei Cassandra nel cluster. |
Upgrade di Kubernetes | Un upgrade di Kubernetes potrebbe influire sul cluster Cassandra. Questo può accadere quando il worker viene eseguito l'upgrade dei nodi che ospitano i pod Cassandra a una nuova versione del sistema operativo. |
Diagnosi
Controlla il log degli errori di Cassandra per determinare la causa del problema.
- Elenca i pod per ottenere l'ID del pod Cassandra in errore:
kubectl get pods -n NAMESPACE
- Controlla il log del pod con problemi:
kubectl logs POD_ID -n NAMESPACE
Risoluzione
Cerca i seguenti indizi nel log del pod:
Il data center è diverso da quello precedente
Se viene visualizzato questo messaggio di log:
Cannot start node if snitch's data center (us-east1) differs from previous data center
- Controlla se nel cluster sono presenti PVC obsolete o obsolete ed eliminale.
- Se si tratta di una nuova installazione, elimina tutte le PVC e riprova a eseguire la configurazione. Ad esempio:
kubectl -n NAMESPACE get pvc
kubectl -n NAMESPACE delete pvc cassandra-data-apigee-cassandra-default-0
L'upgrade di Anthos cambia le impostazioni di sicurezza
Controlla se nei log di Cassandra è presente questo messaggio di errore:
/opt/apigee/run.sh: line 68: ulimit: max locked memory: cannot modify limit: Operation not permitted
- Se l'istanza ibrida è multiregionale, dismissione del modello istanza ed espandi di nuovo le risorse interessate regione.
- Se l'istanza ibrida è una singola regione, esegui un riavvio in sequenza su ciascun pod Cassandra in per l'istanza ibrida.
Crea un contenitore client per il debug
Questa sezione spiega come creare un contenitore client da cui puoi accedere
Utilità di debug Cassandra
ad esempio cqlsh
. Queste utilità consentono di eseguire query sulle tabelle Cassandra
può essere utile per il debug.
Crea il container client
Per creare il contenitore client:
- Il container deve utilizzare il certificato TLS di
apigee-cassandra-user-setup
pod. Questo viene archiviato come secret di Kubernetes. Recupera il nome del secret in cui è archiviato questo certificato:kubectl get secrets -n apigee --field-selector type=kubernetes.io/tls | grep apigee-cassandra-user-setup | awk '{print $1}'
Questo comando restituisce il nome del secret. Ad esempio:
apigee-cassandra-user-setup-rg-hybrid-b7d3b9c-tls
. Lo utilizzerai di seguito nel camposecretName
del file YAML. - Apri un nuovo file e incolla al suo interno la seguente specifica del pod:
apiVersion: v1 kind: Pod metadata: labels: name: CASSANDRA_CLIENT_NAME # For example: my-cassandra-client namespace: apigee spec: containers: - name: CASSANDRA_CLIENT_NAME image: "gcr.io/apigee-release/hybrid/apigee-hybrid-cassandra-client:YOUR_APIGEE_HYBRID_VERSION" # For example, 1.10.5. imagePullPolicy: Always command: - sleep - "3600" env: - name: CASSANDRA_SEEDS value: apigee-cassandra-default.apigee.svc.cluster.local - name: APIGEE_DML_USER valueFrom: secretKeyRef: key: dml.user name: apigee-datastore-default-creds - name: APIGEE_DML_PASSWORD valueFrom: secretKeyRef: key: dml.password name: apigee-datastore-default-creds volumeMounts: - mountPath: /opt/apigee/ssl name: tls-volume readOnly: true volumes: - name: tls-volume secret: defaultMode: 420 secretName: YOUR_SECRET_NAME # For example: apigee-cassandra-user-setup-rg-hybrid-b7d3b9c-tls restartPolicy: Never
- Salva il file con l'estensione
.yaml
. Ad esempio:my-spec.yaml
. - Applica la specifica al cluster:
kubectl apply -f YOUR_SPEC_FILE.yaml -n apigee
- Accedi al container:
kubectl exec -n apigee CASSANDRA_CLIENT_NAME -it -- bash
- Connettiti all'interfaccia
cqlsh
di Cassandra con il seguente comando. Inserisci il esattamente come mostrato:cqlsh ${CASSANDRA_SEEDS} -u ${APIGEE_DML_USER} -p ${APIGEE_DML_PASSWORD} --ssl
Eliminazione del pod client
Utilizza questo comando per eliminare il pod del client Cassandra:
kubectl delete pods -n apigee cassandra-client
Espansione della regione configurata in modo errato: tutti i nodi Cassandra in un data center
Questa situazione si verifica in un'espansione multiregionale su piattaforme GKE e GKE On-Prem (Anthos). Cerca di evitare di creare tutti i tuoi Nodi Cassandra nello stesso data center.
Sintomo
Impossibile creare i nodi Cassandra nel data center per la seconda regione.
Messaggio di errore
failed to rebuild from dc-1: java.lang.RuntimeException : Error while rebuilding node: Stream failed
Risoluzione
Correggi l'espansione della regione configurata in modo errato seguendo questa procedura:
- Aggiorna il
replicaCount
di Cassandra in1
neloverrides.yaml
per il secondo data center. Ad esempio:cassandra: . . . replicaCount: 1
Applica l'impostazione con
apigeectl apply
:$APIGEECTL_HOME/apigeectl apply -f 2ND_DATACENTER_OVERRIDES.yaml
- Utilizza
kubectl exec
per accedere al pod Cassandra rimanente con il seguente comando:kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
- Dismetti il pod Cassandra rimanente con il seguente comando:
nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD decommission
- Elimina i pod Cassandra dal secondo data center utilizzando
apigeectl delete
con l'argomento--datastore
. Ad esempio:$APIGEECTL_HOME/apigeectl delete -f 2ND_DATACENTER_OVERRIDES.yaml --datastore
- Cambia il contesto di Kubernetes con il cluster per il tuo primo data center:
kubectl config use-context FIRST_DATACENTER_CLUSTER
- Verifica che non esistano nodi Cassandra in stato inattivo nel primo data center.
nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD status
- Verificare che i nodi Cassandra configurati in modo errato (destinati al secondo data center) siano stati
rimosso dal primo data center. Assicurati che gli indirizzi IP visualizzati
L'output dello stato nodetool è costituito solo dagli indirizzi IP dei pod Cassandra destinati
il primo data center. Ad esempio, nel seguente output l'indirizzo IP
10.100.0.39
dovrebbe essere per un pod nel tuo primo data center.kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD status
Datacenter: dc-1 ================ Status=U/D (Up/Down) | State=N/L/J/M (Normal/Leaving/Joining/Moving) -- Address Load Tokens Owns (effective) Host ID Rack UN 10.100.0.39 4.21 MiB 256 100.0% a0b1c2d3-e4f5-6a7b-8c9d-0e1f2a3b4c5d ra-1 - Verifica che il file
overrides.yaml
del secondo data center contenga l'impostazione del nome del data center nella sezione cassandra. Ad esempio:cassandra: datacenter: DATA_CENTER_2 rack: "RACK_NAME" # "ra-1" is the default value. . . .
- Aggiorna l'impostazione
cassandra:replicaCount
nel fileoverrides.yaml
per secondo data center al numero desiderato. Ad esempio:cassandra: datacenter: DATA_CENTER_2 . . . replicaCount: 3
- Applica il file
overrides.yaml
per il secondo data center con--datastore
. Ad esempio:$APIGEECTL_HOME/apigeectl apply -f 2ND_DATACENTER_OVERRIDES.yaml --datastore
- Utilizza
kubectl exec
per accedere a uno dei nuovi pod Cassandra nel secondo e verificare che esistano due data center:"nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD status"
Risorse aggiuntive
Vedi Introduzione ai playbook ibridi di Apigee X e Apigee.