- v1.12 (più recente)
- Versione 1.11
- Versione 1.10
- Elenco delle versioni supportate
- Versione 1.9
- Versione 1.8
- Versione 1.7
- Versione 1.6
- Versione 1.5
- Versione 1.4
- Versione 1.3
- Versione 1.2
- Versione 1.1
Versioni supportate:
Versioni non supportate:
Questo argomento illustra i passaggi che puoi intraprendere per risolvere i problemi relativi al datastore Cassandra. Cassandra è un datastore permanente che viene eseguito nel componente cassandra
dell'architettura di runtime ibrida.
Vedi anche Panoramica della configurazione del servizio di runtime.
I pod Cassandra sono bloccati nello stato In attesa
Sintomo
All'avvio, i pod Cassandra rimangono nello stato In attesa.
Messaggio di errore
Quando utilizzi kubectl
per visualizzare gli stati dei pod, vedrai che uno o più pod Cassandra sono bloccati nello stato Pending
. 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 più cause. Ad esempio:
Causa | Descrizione |
---|---|
Risorse insufficienti | CPU o memoria disponibile non sufficiente per creare il pod. |
Volume non creato | Il pod è in attesa della creazione del volume permanente. |
Diagnosi
Utilizza 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 dei seguenti problemi possibili:
- Se il problema non è sufficiente, verrà visualizzato un messaggio di avviso che indica CPU o memoria insufficienti.
- Se il messaggio di errore indica che il pod ha richieste PersistentVolumeClaim (PVC) immediate non associate, significa che il pod non è in grado di creare il proprio volume permanente.
Risoluzione
Risorse insufficienti
Modifica il pool di nodi Cassandra in modo che disponga di risorse di CPU e memoria sufficienti. Per maggiori dettagli, consulta Ridimensionamento di un pool di nodi.
Volume permanente non creato
Se determini un problema di volume permanente, descrivi l'oggetto PersistentVolumeClaim (PVC) per determinare il motivo per cui 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 con errori. Ad esempio, il comando seguente
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
In questo esempio, l'oggetto StorageClass denominato
apigee-sc
non esiste. Per risolvere il problema, crea l'oggetto StorageClass mancante nel cluster, come spiegato in Modificare il valore predefinito di StorageClass.
Vedi anche Debug dei pod.
I pod Cassandra sono bloccati nello stato CrashLoopBackoff
Sintomo
All'avvio, i pod Cassandra rimangono nello stato CrashLoopBackoff.
Messaggio di errore
Quando utilizzi kubectl
per visualizzare gli stati dei pod, vedi che uno o più 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 più cause. Ad esempio:
Causa | Descrizione |
---|---|
Il data center è diverso dal precedente data center | Questo errore indica che il pod Cassandra ha un volume permanente che contiene dati di un cluster precedente e che i nuovi pod non sono in grado di unire il cluster precedente. Questo accade di solito quando volumi permanenti inattivi persistono dal cluster Cassandra precedente sullo stesso nodo Kubernetes. Questo problema può verificarsi se elimini e ricrei Cassandra nel cluster. |
Directory dell'archivio attendibilità non trovata | Questo errore indica che il pod Cassandra non è in grado di creare una connessione TLS. Questo di solito si verifica quando le chiavi e i certificati forniti non sono validi, mancano o presentano altri problemi. |
Diagnosi
Controlla il log degli errori Cassandra per determinare la causa del problema.
- Elenca i pod per ottenere l'ID del pod Cassandra che non funziona:
kubectl get pods -n namespace
- Controlla il log del pod con errori:
kubectl logs pod_id -n namespace
Risoluzione
Cerca i seguenti indizi nel log del pod:
Il data center è diverso dal precedente data center
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 vecchi o inattivi ed eliminali.
- 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
Directory dell'archivio attendibilità non trovata
Se viene visualizzato questo messaggio di log:
Caused by: java.io.FileNotFoundException: /apigee/cassandra/ssl/truststore.p12 (No such file or directory)
Verifica che la chiave e i certificati, se forniti nel file di override, siano corretti e validi. Ad esempio:
cassandra: sslRootCAPath: path_to_root_ca-file sslCertPath: path-to-tls-cert-file sslKeyPath: path-to-tls-key-file
Errore del nodo
Sintomo
All'avvio, i pod Cassandra rimangono in stato In attesa. Questo problema può indicare un errore di un nodo sottostante.
Diagnosi
- Determina quali pod Cassandra non sono in esecuzione:
$ kubectl get pods -n your_namespace NAME READY STATUS RESTARTS AGE cassandra-default-0 0/1 Pending 0 13s cassandra-default-1 1/1 Running 0 8d cassandra-default-2 1/1 Running 0 8d
- Controlla i nodi worker. Se è nello stato NotReady, significa che si tratta del nodo che non è riuscito:
kubectl get nodes -n your_namespace NAME STATUS ROLES AGE VERSION INTERNAL-IP gke-hybrid-cluster-apigee-data-178811f1-lv5j Ready <none> 34d v1.21.5-gke.1302 10.138.15.198 gke-hybrid-cluster-apigee-data-d63b8b8d-n41g NotReady <none> 34d v1.21.5-gke.1302 10.138.15.200 gke-hybrid-cluster-apigee-data-ec752c0b-b1cr Ready <none> 34d v1.21.5-gke.1302 10.138.15.199 gke-hybrid-cluster-apigee-runtime-ba502ff4-57mq Ready <none> 34d v1.21.5-gke.1302 10.138.15.204 gke-hybrid-cluster-apigee-runtime-ba502ff4-hwkb Ready <none> 34d v1.21.5-gke.1302 10.138.15.203 gke-hybrid-cluster-apigee-runtime-bfa558e0-08vw Ready <none> 34d v1.21.5-gke.1302 10.138.15.201 gke-hybrid-cluster-apigee-runtime-bfa558e0-xvsc Ready <none> 34d v1.21.5-gke.1302 10.138.15.202 gke-hybrid-cluster-apigee-runtime-d12de7df-693w Ready <none> 34d v1.21.5-gke.1302 10.138.15.241 gke-hybrid-cluster-apigee-runtime-d12de7df-fn0w Ready <none> 34d v1.21.5-gke.1302 10.138.15.206
Risoluzione
- Rimuovi il pod Cassandra defunto dal cluster.
$ kubectl exec -it apigee-cassandra-default-0 -- nodetool status
$ kubectl exec -it apigee-cassandra-default-0 -- nodetool removenode deadnode_hostID
- Rimuovi l'oggetto VolumeClaim dal nodo inattivo per impedire al pod Cassandra di tentare di crearsi sul nodo inattivo a causa dell'affinità:
kubectl get pvc -n your_namespace
kubectl delete pvc volumeClaim_name -n your_namespace
- Aggiorna il modello di volume e crea un PersistentVolume per il nodo appena aggiunto. Di seguito è riportato un esempio di modello di volume:
apiVersion: v1 kind: PersistentVolume metadata: name: cassandra-data-3 spec: capacity: storage: 100Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain storageClassName: local-storage local: path: /apigee/data nodeAffinity: "required": "nodeSelectorTerms": - "matchExpressions": - "key": "kubernetes.io/hostname" "operator": "In" "values": ["gke-hybrid-cluster-apigee-data-d63b8b8d-n41g"]
- Sostituisci i valori con il nuovo nome host/IP e applica il modello:
kubectl apply -f volume-template.yaml
Crea un contenitore client per il debug
Questa sezione spiega come creare un container client da cui accedere alle utilità di debug di Cassandra, come cqlsh
. Queste utilità consentono di eseguire query sulle tabelle Cassandra e possono essere utili per il debug.
Crea il contenitore client
Per creare il contenitore client:
- Il container utilizza il certificato TLS del pod
apigee-cassandra-user-setup
. Il primo passaggio consiste nel recuperare il nome di 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 certificato. Ad esempio:
apigee-cassandra-user-setup-rg-hybrid-b7d3b9c-tls
. - Apri un nuovo file e incolla al suo interno le seguenti specifiche 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:1.7.6" 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 un'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 -it -- bash
- Connettiti all'interfaccia
cqlsh
di Cassandra con il seguente comando. Inserisci il comando 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
Risorse aggiuntive
Consulta l' Introduzione ai playbook ibridi di Apigee e Apigee.