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 ibrida.
Consulta anche la pagina Panoramica della configurazione del servizio di runtime.
I pod di Cassandra sono bloccati nello stato In attesa
Sintomo
All'avvio, i pod di Cassandra rimangono nello stato In attesa.
Messaggio di errore
Quando utilizzi kubectl per visualizzare gli stati dei pod, puoi notare 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 | La CPU o la 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:
- Se il problema riguarda risorse insufficienti, vedrai un messaggio di avviso che indica una CPU o una 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 il suo volume permanente.
Risoluzione
Risorse insufficienti
Modificare 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 stabilisci un problema di volume permanente, descrivi la PersistentVolumeClaim (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 in errore. 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
In questo esempio, l'oggetto StorageClass denominato
apigee-scnon esiste. Per risolvere questo 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 si bloccano nello stato CrashLoopBackoff
Sintomo
All'avvio, i pod di Cassandra rimangono nello stato CrashLoopBackoff.
Messaggio di errore
Quando utilizzi kubectl per visualizzare gli stati dei pod, puoi notare che uno o più pod di 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 di un cluster precedente e che i nuovi pod non possono unirsi al vecchio cluster. Questo di solito si verifica quando i volumi permanenti inattivi vengono eliminati dal cluster Cassandra precedente sullo stesso nodo Kubernetes. Questo problema può verificarsi se elimini e ricrea Cassandra nel cluster. |
| Directory Truststore non trovata | Questo errore indica che il pod Cassandra non è in grado di creare una connessione TLS. Questo di solito accade quando le chiavi e i certificati forniti non sono validi, mancano o presentano altri problemi. |
Diagnosi
Controlla il log degli errori di Cassandra per determinarne la causa.
- Elenca i pod per ottenere l'ID del pod Cassandra in errore:
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 è presente PVC obsoleta o obsoleta 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-default-0
Directory Truststore 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 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 nodo
Sintomo
All'avvio, i pod di Cassandra rimangono nello stato In attesa. Questo problema può indicare un guasto sottostante del nodo.
Diagnosi
- Stabilisci 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 è in stato NotReady, significa che il nodo è in 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 inattivo dal cluster.
$ kubectl exec -it apigee-cassandra-default-0 -- nodetool status
$ kubectl exec -it apigee-cassandra-default-0 -- nodetool removenode deadnode_hostID - Rimuovi il volumeClaim dal nodo inattivo per impedire al pod Cassandra di tentare la visualizzazione del nodo inattivo 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 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
Crea un container client per il debug
Questa sezione spiega come creare un container client da cui puoi accedere alle utilità di debug Cassandra, come cqlsh. Queste utilità ti consentono di eseguire query sulle tabelle di Cassandra e possono
essere utili per scopi di debug.
Crea il container client
Per creare il contenitore del client:
- Il container utilizza il certificato TLS del pod
apigee-cassandra-user-setup. Il primo passaggio è il recupero di questo nome del 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 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:1.9.0" 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 tuo cluster:
kubectl apply -f your-spec-file.yaml -n apigee
- Accedi al container:
kubectl exec -n apigee cassandra-client -it -- bash
- Per connetterti all'interfaccia di Cassandra
cqlsh, esegui il comando seguente. 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 client Cassandra:
kubectl delete pods -n apigee cassandra-client
Risorse aggiuntive
Consulta la pagina Introduzione ai playbook ibridi di Apigee e Apigee.