Guida alla risoluzione dei problemi di Cassandra

Stai visualizzando la versione 1.8 di Documentazione di Apigee hybrid. This version is end of life. You should upgrade to a newer version. Per ulteriori informazioni, vedi Versioni supportate.

Version 1.8 (unsupported)

   Versioni supportate:

• v1.13 (più recente)                        
• v1.12                         
• v1.11                         
• Elenco delle versioni supportate

Versioni non supportate:

• v1.10                                      
• v1.9                                         
• v1.8                                         
• v1.7                                         
• v1.6                                         
• v1.5                                         
• v1.4                                         
• v1.3                                         
• v1.2                                         
• v1.1                                         

Questo argomento illustra i passaggi che puoi seguire per risolvere i problemi relativi al datastore Cassandra. Cassandra è un datastore permanente in esecuzione nel componente cassandra dell' architettura di runtime ibrida. Consulta anche Panoramica della configurazione dei servizi di runtime.

I pod Cassandra sono bloccati nello stato In attesa

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-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	Non è disponibile 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 Amazon EBS CSI richiesto non è installato.

Diagnosi

Utilizza kubectl per descrivere il pod al fine di 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 è costituito da risorse insufficienti, verrà visualizzato un messaggio di avviso che indica CPU o memoria insufficiente.
• 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 di volume permanente, descrivi l'oggetto PersistentVolumeClaim (PVC) per determinare perché non viene creato:

1. 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
   ...

2. Descrivi la 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-sc non esiste. A risolvere il problema, creare l'oggetto StorageClass mancante nel cluster, come spiegato in Modificare il valore predefinito del campo StorageClass.

Vedi anche Eseguire il debug dei pod.

Driver CSI Amazon EBS mancante

Se l'istanza ibrida è in esecuzione su un cluster EKS, assicurati che quest'ultimo utilizzi Driver Amazon EBS Container Storage Interface (CSI). Per maggiori dettagli, consulta le domande frequenti sulla migrazione di Amazon EBS CSI.

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-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 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 del 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, sono mancanti o sono problemi.

Diagnosi

Controlla il log degli errori di Cassandra per determinare la causa del problema.

1. Elenca i pod per ottenere l'ID del pod Cassandra che presenta errori:

   kubectl get pods -n namespace

2. Controlla il log del pod con problemi:

   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 obsoleti o non aggiornati ed eliminali.
• Se si tratta di una nuova installazione, elimina tutti i 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 delle sostituzioni, 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

Crea un contenitore client per il debug

Questa sezione spiega come creare un contenitore client da cui puoi accedere alle utility di debug di Cassandra come cqlsh. Queste utilità ti consentono di eseguire query sulle tabelle Cassandra e possono essere utili per il debug.

Crea il container client

Per creare il contenitore client:

1. Il contenitore utilizza il certificato TLS del pod apigee-cassandra-user-setup. Il primo passaggio consiste nell'estrarre 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.

2. 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

3. Salva il file con l'estensione .yaml. Ad esempio: my-spec.yaml.
4. Applica la specifica al cluster:

   kubectl apply -f your-spec-file.yaml -n apigee

5. Accedi al contenitore:

   kubectl exec -n apigee cassandra-client -it -- bash

6. 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 la Guida introduttiva alle guide pratiche di Apigee e Apigee hybrid.