Questo argomento illustra i passaggi da seguire per risolvere i problemi del datastore Cassandra. Cassandra è un
datastore permanente eseguito
nel componente cassandra
dell'architettura di runtime ibrido.
Vedi anche la panoramica della configurazione del servizio 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, puoi vedere 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 | Memoria o CPU insufficiente 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 -n apigee describe pods apigee-cassandra-default-0
L'output potrebbe mostrare uno dei seguenti problemi:
- Se le risorse sono insufficienti, vedrai un messaggio di avviso che indica che la CPU o la memoria non sono sufficienti.
- Se il messaggio di errore indica che il pod ha richieste di volumi permanenti immediate non associate al pod, significa che il pod non è in grado di creare il suo volume permanente.
Risoluzione
Risorse insufficienti
Modifica il pool di nodi Cassandra in modo che abbia risorse sufficienti per CPU e memoria. Per maggiori dettagli, consulta la sezione Ridimensionare un pool di nodi.
Volume permanente non creato
Se stabilisci un problema di volume permanente, descrivi la richiesta di volume permanente (PVC) per determinare perché non viene creata:
- 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 non funziona. Ad esempio, il seguente comando
descrive il PVC associato 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 nella sezione Modificare l'oggetto StorageClass predefinito.
Vedi anche Debug dei pod.
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, puoi vedere 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 |
---|---|
I data center sono diversi da quelli precedenti | Questo errore indica che il pod Cassandra ha un volume permanente con dati provenienti da un cluster precedente e che i nuovi pod non sono in grado di accedere al cluster precedente. Questo di solito si verifica quando i volumi permanenti inattivi rimangono dal precedente cluster Cassandra sullo stesso nodo Kubernetes. Questo problema può verificarsi se elimini e ricrei Cassandra nel cluster. |
Directory archivio attendibilità non trovata | Questo errore indica che il pod Cassandra non è in grado di creare una connessione TLS. In genere questo accade 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 trovare l'ID del pod di Cassandra con errori:
kubectl get pods -n namespace
- Controlla il log del pod in errore:
kubectl logs pod_id -n namespace
Risoluzione
Cerca i seguenti indizi nel log del pod:
I data center sono diversi da quelli precedenti
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 oggetti PVC obsoleti o inattivi ed eliminali.
- Se l'installazione è nuova, 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 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 forniti nel file delle sostituzioni 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 nodo
Sintomo
All'avvio, i pod Cassandra rimangono in stato di attesa. Questo problema può indicare un errore di nodo sottostante.
Diagnosi
- Individua i pod di Cassandra 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 è in stato NotReady, il nodo che non ha superato il test:
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 attivo 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 non attivo per impedire
al pod Cassandra di tentare di accedere al nodo non attivo
a causa dell'affinità:
kubectl get pvc -n your_namespace
kubectl delete pvc volumeClaim_name -n your_namespace
- Aggiorna il modello del volume e crea un oggetto PersistentVolume per il nodo appena aggiunto. Di seguito è riportato un modello di volume di esempio:
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