Guida alla risoluzione dei problemi relativi a Cassandra

Attualmente stai visualizzando la versione 1.3 della documentazione ibrida di Apigee. Questa versione è terminata. Dovresti eseguire l'upgrade a una versione più recente. Per ulteriori informazioni, consulta la sezione Versioni supportate.

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:

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

1. Elenca i pod per trovare l'ID del pod di Cassandra con errori:

   kubectl get pods -n namespace

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

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

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

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

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

3. 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"]

4. Sostituisci i valori con il nuovo nome host/IP e applica il modello:

   kubectl apply -f volume-template.yaml