Questa pagina è stata tradotta dall'API Cloud Translation.

Guida alla risoluzione dei problemi di Cassandra

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.

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

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 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. Per risolvere il problema, crea la risorsa StorageClass mancante nel cluster, come spiegato in Modificare la risorsa StorageClass predefinita.

Vedi anche Debug dei pod.

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 pvc
kubectl -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

Errore del nodo

Sintomo

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

Diagnosi

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

Controlla i nodi worker. Se uno è nello stato NotReady, allora è il nodo che ha generato l'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 non funzionante dal cluster.

$ kubectl exec -it apigee-cassandra-default-0 -- nodetool status
$ kubectl exec -it apigee-cassandra-default-0 -- nodetool removenode deadnode_hostID

Rimuovi VolumeClaim dal nodo non funzionante per impedire al pod Cassandra di tentare di avviarsi sul nodo non funzionante a causa dell'affinità:
```
kubectl get pvc -n your_namespace
kubectl delete pvc volumeClaim_name -n your_namespace
```

Aggiorna il modello di volume e crea PersistentVolume per il nodo 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": ["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 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 |grep "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.

Poi recupera il nome del secret del datastore:

kubectl get secrets -n apigee | grep "datastore.*-creds" | awk '{print $1}'

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.5.10"
    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: default-datastore-creds  # The datastore secret name fetched previously.
    - name: APIGEE_DML_PASSWORD
      valueFrom:
        secretKeyRef:
          key: dml.password
          name: default-datastore-creds  # The datastore secret name fetched previously.
    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 cqlsh 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 client Cassandra:

kubectl delete pods -n apigee cassandra-client

Risorse aggiuntive

Consulta Introduzione alle guide pratiche di Apigee e Apigee hybrid.

Guida alla risoluzione dei problemi di Cassandra Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

I pod di Cassandra sono bloccati nello stato In attesa

Sintomo

Messaggio di errore

Cause possibili

Diagnosi

Risoluzione

Risorse insufficienti

Volume permanente non creato

I pod di Cassandra sono bloccati nello stato CrashLoopBackoff

Sintomo

Messaggio di errore

Cause possibili

Diagnosi

Risoluzione

Il data center è diverso dal precedente

Directory Truststore non trovata

Errore del nodo

Sintomo

Diagnosi

Risoluzione

Crea un container client per il debug

Crea il container client

Eliminazione del pod client

Risorse aggiuntive

Guida alla risoluzione dei problemi di Cassandra