Questo argomento descrive i passaggi che puoi eseguire per risolvere e correggere i problemi relativi al datastore Cassandra. Cassandra è un
datastore persistente
che viene eseguito nel componente cassandra dell'architettura di runtime ibrido.
Vedi anche
Panoramica configurazione del servizio di runtime.
I pod di 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, noti 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: 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-default-0 0/1 Pending 0 10m
...Cause possibili
Un pod bloccato nello stato Pending può avere più cause. Ad esempio:
| Causa | Descrizione |
|---|---|
| Risorse insufficienti | Non sono disponibili CPU o memoria sufficienti per creare il pod. |
| Volume non creato | Il pod è in attesa della creazione del volume permanente. |
| Driver CSI Amazon EBS mancante | Il driver CSI Amazon EBS richiesto non è installato. |
Diagnosi
Utilizza kubectl
per descrivere il pod e 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 è dovuto a risorse insufficienti, vedrai un messaggio di avviso che indica CPU o memoria insufficienti.
- Se il messaggio di errore indica che il pod ha richieste di volumi permanenti (PVC) immediate non vincolate, significa che il pod non è in grado di creare il relativo volume permanente.
Risoluzione
Risorse insufficienti
Modifica il pool di nodi Cassandra in modo che disponga di risorse di CPU e memoria sufficienti. Per ulteriori dettagli, consulta la sezione Ridimensionamento di un node pool.
Volume permanente non creato
Se identifichi un problema con il volume permanente, descrivi 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 il PVC per il pod che non funziona. Ad esempio, il seguente comando
descrive la PVC associata al pod
apigee-cassandra-default-0:kubectl -n 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 l'oggetto StorageClass denominato
apigee-scnon esiste. Per risolvere il problema, crea la risorsa StorageClass mancante nel cluster, come spiegato in Modificare la risorsa StorageClass predefinita.
Vedi anche Debug dei pod.
Driver CSI Amazon EBS mancante
Se l'istanza ibrida è in esecuzione su un cluster EKS, assicurati che il cluster EKS utilizzi il driver CSI (Container Storage Interface) di Amazon EBS. Per maggiori dettagli, consulta le Domande frequenti sulla migrazione di Amazon EBS CSI.
I pod di 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, noti che uno o più pod Cassandra si trovano nello 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 | Questo errore indica che il pod Cassandra ha un volume persistente con dati di un cluster precedente e i nuovi pod non riescono a unirsi al vecchio cluster. Ciò si verifica in genere quando i volumi permanenti obsoleti persistono dal cluster Cassandra precedente sullo stesso nodo Kubernetes. Questo problema può verificarsi se elimini e ricrei Cassandra nel cluster. |
| Directory Truststore non trovata | Questo errore indica che il pod Cassandra non è in grado di creare una connessione TLS. Ciò si verifica in genere quando le chiavi e i certificati forniti non sono validi, sono mancanti 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 che non funziona:
kubectl get pods -n namespace
- Controlla il log del pod non riuscito:
kubectl logs pod_id -n namespace
Risoluzione
Cerca i seguenti indizi nel log del pod:
Il data center è diverso dal precedente
Se visualizzi 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 obsoleti o vecchi ed eliminali.
- Se si tratta di una nuova installazione, elimina tutti i PVC e riprova la configurazione. Ad esempio:
kubectl -n namespace get pvckubectl -n namespace delete pvc cassandra-data-apigee-cassandra-default-0
Directory Truststore non trovata
Se visualizzi 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
Crea un container client per il debug
Questa sezione spiega come creare un container client da cui puoi 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 container 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 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 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.8.8" 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 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
- Connettiti all'interfaccia Cassandra
cqlshcon 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 client Cassandra:
kubectl delete pods -n apigee cassandra-client
Risorse aggiuntive
Consulta Introduzione alle guide pratiche di Apigee e Apigee hybrid.