Questo argomento illustra i passaggi che puoi seguire per risolvere i problemi relativi al datastore Cassandra. Cassandra è un
datastore permanente
che viene eseguito nel componente cassandra dell'architettura di runtime ibrida.
Consulta anche
Panoramica della configurazione dei servizi di runtime.
I pod Cassandra sono bloccati nello stato Pending
Sintomo
All'avvio, i pod Cassandra rimangono nello stato Pending (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. Lo stato Pending indica che Kubernetes non è in grado di pianificare il pod su un nodo: il pod non può essere creato. Ad esempio:
kubectl get pods -n namespace
NAME READY STATUS RESTARTS AGE
adah-resources-install-4762w 0/4 Completed 0 10m
apigee-cassandra-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 | Non è disponibile CPU o memoria sufficienti per creare il pod. |
| Volume non creato | Il pod è in attesa della creazione del volume permanente. |
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 -n apigee describe pods apigee-cassandra-0
L'output potrebbe mostrare uno di questi possibili problemi:
- Se il problema è dovuto a risorse insufficienti, viene visualizzato un messaggio di avviso che indica la CPU o la memoria insufficienti.
- Se il messaggio di errore indica che il pod ha richieste di volumi permanenti (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 CPU e memoria sufficienti. Per ulteriori dettagli, consulta la sezione Ridimensionare un pool di nodi.
Volume permanente non creato
Se rilevi un problema con il volume permanente, descrivi il 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-0 Bound pvc-b247faae-0a2b-11ea-867b-42010a80006e 10Gi RWO standard 15m ...
- Descrivi la PVC per il pod che non funziona. Ad esempio, il seguente comando descrive la PVC associata al pod
apigee-cassandra-0:kubectl apigee describe pvc cassandra-data-apigee-cassandra-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 l'oggetto StorageClass denominato
apigee-scnon esiste. A risolvere il problema, creare l'oggetto StorageClass mancante nel cluster, come spiegato in Modificare il valore predefinito del campo StorageClass.
Vedi anche di 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ù
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-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 rimangono volumi permanenti inattivi dalla versione precedente di Cassandra di un cluster Kubernetes 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 accade in genere quando le chiavi e i certificati forniti non sono validi, mancano o presentano altri problemi. |
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 errori:
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 pvckubectl -n namespace delete pvc cassandra-data-apigee-cassandra-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 degli override, siano corretti e validi. Per 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 del nodo sottostante.
Diagnosi
- Determina quali pod Cassandra non sono in esecuzione:
$ kubectl get pods -n your_namespace NAME READY STATUS RESTARTS AGE cassandra-0 0/1 Pending 0 13s cassandra-1 1/1 Running 0 8d cassandra-2 1/1 Running 0 8d
- Controlla i nodi worker. Se uno è nello stato NotReady,
si tratta del nodo che ha riscontrato un errore:
kubectl get nodes -n your_namespace NAME STATUS ROLES AGE VERSION ip-10-30-1-190.ec2.internal Ready <none> 8d v1.13.2 ip-10-30-1-22.ec2.internal Ready master 8d v1.13.2 ip-10-30-1-36.ec2.internal NotReady <none> 8d v1.13.2 ip-10-30-2-214.ec2.internal Ready <none> 8d v1.13.2 ip-10-30-2-252.ec2.internal Ready <none> 8d v1.13.2 ip-10-30-2-47.ec2.internal Ready <none> 8d v1.13.2 ip-10-30-3-11.ec2.internal Ready <none> 8d v1.13.2 ip-10-30-3-152.ec2.internal Ready <none> 8d v1.13.2 ip-10-30-3-5.ec2.internal Ready <none> 8d v1.13.2
Risoluzione
- Rimuovi il pod Cassandra non funzionante dal cluster.
$ kubectl exec -it apigee-cassandra-0 -- nodetool status
$ kubectl exec -it apigee-cassandra-0 -- nodetool removenode deadnode_hostID - Rimuovi la richiesta di volume dal nodo non funzionante per impedire al
pod Cassandra di tentare di avviarsi sul nodo non funzionante 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 PersistentVolume per il
node 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": ["ip-10-30-1-36.ec2.internal"]
- Sostituisci i valori con il nuovo nome host/IP e applica il modello:
kubectl apply -f volume-template.yaml