Guida alla risoluzione dei problemi di Cassandra

Questo argomento illustra i passaggi che puoi seguire per risolvere i problemi relativi al datastore Cassandra. Cassandra è un datastore permanente che viene eseguito 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, noti che uno o più pod Cassandra sono bloccati nello stato Pending. La 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 Non è disponibile CPU o memoria sufficienti per creare il pod.
Volume non creato Il pod è in attesa della creazione del volume permanente.

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 -n apigee describe pods apigee-cassandra-default-0

L'output potrebbe mostrare uno di questi possibili problemi:

  • Se il problema è dovuto a risorse insufficienti, viene visualizzato un messaggio di avviso che indica la CPU o la memoria insufficienti.
  • 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. Vedi Ridimensionamento di un pool di nodi per maggiori dettagli.

Volume permanente non creato

Se rilevi un problema con il volume permanente, descrivi il 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 del pod che presenta errori. 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

    Tieni presente che in questo esempio non esiste un oggetto StorageClass denominato apigee-sc. Per risolvere il problema, crea la risorsa StorageClass mancante nel cluster, come spiegato in Modificare la risorsa StorageClass predefinita.

Vedi anche Eseguire il debug dei pod.

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, noti che uno o più pod Cassandra sono 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 da quello precedente Questo errore indica che il pod Cassandra ha un volume permanente contenente i dati di un cluster precedente e che i nuovi pod non sono in grado di partecipare al vecchio cluster. 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 dell'archivio attendibilità non trovata Questo errore indica che il pod Cassandra non è in grado di creare una connessione TLS. Questo accade in genere quando le chiavi e i certificati forniti non sono validi, mancano o presentano altri 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 errori: 
    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 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 del 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, se forniti nel file degli 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 del nodo

Sintomo

All'avvio, i pod Cassandra rimangono in stato In attesa. Questo problema può indicare un errore del nodo sottostante.

Diagnosi

  1. Determina 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
  2. Controlla i nodi worker. Se uno è nello stato NotReady, si tratta del nodo che ha riscontrato un errore: 
    kubectl get nodes -n your_namespace
NAME                                              STATUS   ROLES    AGE   VERSION            INTERNAL-IP
gke-hybrid-cluster-apigee-data-178811f1-lv5j      Ready    <none>   34d   v1.21.5-gke.1302   10.138.15.198
gke-hybrid-cluster-apigee-data-d63b8b8d-n41g      NotReady <none>   34d   v1.21.5-gke.1302   10.138.15.200
gke-hybrid-cluster-apigee-data-ec752c0b-b1cr      Ready    <none>   34d   v1.21.5-gke.1302   10.138.15.199
gke-hybrid-cluster-apigee-runtime-ba502ff4-57mq   Ready    <none>   34d   v1.21.5-gke.1302   10.138.15.204
gke-hybrid-cluster-apigee-runtime-ba502ff4-hwkb   Ready    <none>   34d   v1.21.5-gke.1302   10.138.15.203
gke-hybrid-cluster-apigee-runtime-bfa558e0-08vw   Ready    <none>   34d   v1.21.5-gke.1302   10.138.15.201
gke-hybrid-cluster-apigee-runtime-bfa558e0-xvsc   Ready    <none>   34d   v1.21.5-gke.1302   10.138.15.202
gke-hybrid-cluster-apigee-runtime-d12de7df-693w   Ready    <none>   34d   v1.21.5-gke.1302   10.138.15.241
gke-hybrid-cluster-apigee-runtime-d12de7df-fn0w   Ready    <none>   34d   v1.21.5-gke.1302   10.138.15.206

Risoluzione

  1. Rimuovi il pod Cassandra non funzionante dal cluster. 
    $ kubectl exec -it apigee-cassandra-default-0 -- nodetool status
$ kubectl exec -it apigee-cassandra-default-0 -- nodetool removenode deadnode_hostID
  2. Rimuovi VolumeClaim dal nodo inattivo per evitare del pod Cassandra di non tentare di trovare un nodo inattivo dell'affinità: 
    kubectl get pvc -n your_namespace
kubectl delete pvc volumeClaim_name -n your_namespace
  3. Aggiornare il modello di volume e creare PersistentVolume per appena aggiunto. Di seguito è riportato un esempio di modello di volume: 
    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": ["gke-hybrid-cluster-apigee-data-d63b8b8d-n41g"]
  4. Sostituisci i valori con il nuovo nome host/IP e applica il modello: 
    kubectl apply -f volume-template.yaml

Crea un contenitore client per il debug

Questa sezione spiega come creare un contenitore client da cui puoi accedere Utilità di debug Cassandra ad esempio cqlsh. Queste utilità consentono di eseguire query sulle tabelle Cassandra può essere utile per il debug.

Crea il contenitore del client

Per creare il contenitore client:

  1. Il container utilizza il certificato TLS dell'apigee-cassandra-user-setup pod. 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 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.6.9"
    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 un'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 container: 
    kubectl exec -n apigee cassandra-client -it -- bash
  6. Connettiti all'interfaccia cqlsh di Cassandra con il seguente comando. Inserisci il 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.