Esta página se ha traducido con Cloud Translation API.

Guía para solucionar problemas de Cassandra

En este tema se describen los pasos que puedes seguir para solucionar problemas con el almacén de datos Cassandra. Cassandra es un almacén de datos persistente que se ejecuta en el componente cassandra de la arquitectura de tiempo de ejecución híbrida. Consulta también la información general sobre la configuración del servicio del entorno de ejecución.

Los pods de Cassandra se quedan en el estado Pendiente

Síntoma

Al iniciarse, los pods de Cassandra permanecen en el estado Pendiente.

Mensaje de error

Cuando usas kubectl para ver los estados de los pods, observas que uno o varios pods de Cassandra están bloqueados en el estado Pending. El estado Pending indica que Kubernetes no puede programar el pod en un nodo, por lo que no se puede crear. Por ejemplo:

kubectl get pods -n namespace

NAME                                     READY   STATUS      RESTARTS   AGE
adah-resources-install-4762w             0/4     Completed   0          10m
apigee-cassandra-0                       0/1     Pending     0          10m
...

Posibles motivos

Un pod que se queda en el estado Pending puede deberse a varios motivos. Por ejemplo:

Causa	Descripción
Recursos insuficientes	No hay suficiente CPU o memoria disponible para crear el pod.
No se ha creado el volumen	El pod está esperando a que se cree el volumen persistente.

Diagnóstico

Usa kubectl para describir el pod y determinar la fuente del error. Por ejemplo:

kubectl -n namespace describe pods pod_name

Por ejemplo:

kubectl -n apigee describe pods apigee-cassandra-0

En la salida puede aparecer uno de estos problemas:

Si el problema es que no hay suficientes recursos, verás un mensaje de advertencia que indica que no hay suficiente CPU o memoria.
Si el mensaje de error indica que el pod tiene reclamaciones de volumen persistente inmediatas sin enlazar, significa que el pod no puede crear su volumen persistente.

Resolución

Recursos insuficientes

Modifica el grupo de nodos de Cassandra para que tenga suficientes recursos de CPU y memoria. Para obtener más información, consulta Cambiar el tamaño de un grupo de nodos.

No se ha creado el volumen persistente

Si detectas un problema con el volumen persistente, describe la reclamación de volumen persistente (PVC) para determinar por qué no se crea:

Lista los PVCs del clúster:

kubectl -n namespace get pvc

NAME                                STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
cassandra-data-apigee-cassandra-0   Bound    pvc-b247faae-0a2b-11ea-867b-42010a80006e   10Gi       RWO            standard       15m
...

Describe el PVC del pod que está fallando. Por ejemplo, el siguiente comando describe el PVC enlazado al pod apigee-cassandra-0:

kubectl apigee describe pvc cassandra-data-apigee-cassandra-0

Events:
  Type     Reason              Age                From                         Message
  ----     ------              ----               ----                         -------
  Warning  ProvisioningFailed  3m (x143 over 5h)  persistentvolume-controller  storageclass.storage.k8s.io "apigee-sc" not found

Ten en cuenta que, en este ejemplo, la StorageClass llamada apigee-sc no existe. Para solucionar este problema, crea la StorageClass que falta en el clúster, tal como se explica en Cambiar la StorageClass predeterminada.

Consulta también Depuración de pods.

Los pods de Cassandra se quedan en el estado CrashLoopBackoff

Síntoma

Al iniciarse, los pods de Cassandra permanecen en el estado CrashLoopBackoff.

Mensaje de error

Cuando usas kubectl para ver los estados de los pods, observas que uno o varios pods de Cassandra están en el estado CrashLoopBackoff. Este estado indica que Kubernetes no puede crear el pod. Por ejemplo:

kubectl get pods -n namespace

NAME                                     READY   STATUS            RESTARTS   AGE
adah-resources-install-4762w             0/4     Completed         0          10m
apigee-cassandra-0                       0/1     CrashLoopBackoff           0          10m
...

Posibles motivos

Un pod atascado en el estado CrashLoopBackoff puede deberse a varios motivos. Por ejemplo:

Causa	Descripción
El centro de datos es diferente del anterior	Este error indica que el pod de Cassandra tiene un volumen persistente que contiene datos de un clúster anterior y que los nuevos pods no pueden unirse al clúster antiguo. Esto suele ocurrir cuando los volúmenes persistentes obsoletos persisten del clúster de Cassandra anterior en el mismo nodo de Kubernetes. Este problema puede producirse si eliminas y vuelves a crear Cassandra en el clúster.
No se ha encontrado el directorio del almacén de confianza	Este error indica que el pod de Cassandra no puede crear una conexión TLS. Esto suele ocurrir cuando las claves y los certificados proporcionados no son válidos, faltan o tienen otros problemas.

Causa

Descripción

El centro de datos es diferente del anterior

Este error indica que el pod de Cassandra tiene un volumen persistente que contiene datos de un clúster anterior y que los nuevos pods no pueden unirse al clúster antiguo. Esto suele ocurrir cuando los volúmenes persistentes obsoletos persisten del clúster de Cassandra anterior en el mismo nodo de Kubernetes. Este problema puede producirse si eliminas y vuelves a crear Cassandra en el clúster.

No se ha encontrado el directorio del almacén de confianza

Este error indica que el pod de Cassandra no puede crear una conexión TLS. Esto suele ocurrir cuando las claves y los certificados proporcionados no son válidos, faltan o tienen otros problemas.

Diagnóstico

Consulta el registro de errores de Cassandra para determinar la causa del problema.

Lista los pods para obtener el ID del pod de Cassandra que está fallando:
```
kubectl get pods -n namespace
```
Consulta el registro del pod que falla:
```
kubectl logs pod_id -n namespace
```

Resolución

Busca las siguientes pistas en el registro del pod:

El centro de datos es diferente del anterior

Si ves este mensaje de registro:

Cannot start node if snitch's data center (us-east1) differs from previous data center

Comprueba si hay PVCs obsoletos o antiguos en el clúster y elimínalos.
Si se trata de una instalación nueva, elimina todos los PVCs y vuelve a intentar la configuración. Por ejemplo:
```
kubectl -n namespace get pvc
kubectl -n namespace delete pvc cassandra-data-apigee-cassandra-0
```

No se ha encontrado el directorio del almacén de confianza

Si ves este mensaje de registro:

Caused by: java.io.FileNotFoundException: /apigee/cassandra/ssl/truststore.p12
(No such file or directory)

Comprueba que la clave y los certificados que se proporcionan en el archivo de anulaciones sean correctos y válidos. Por ejemplo:

cassandra:
  sslRootCAPath: path_to_root_ca-file
  sslCertPath: path-to-tls-cert-file
  sslKeyPath: path-to-tls-key-file

Fallo de nodo

Síntoma

Al iniciarse, los pods de Cassandra permanecen en el estado Pending. Este problema puede indicar un fallo subyacente del nodo.

Diagnóstico

Determina qué pods de Cassandra no se están ejecutando:

$ kubectl get pods -n your_namespace
    NAME          READY   STATUS    RESTARTS   AGE
    cassandra-0   0/1     Pending   0          13s
    cassandra-1   1/1     Running   0          8d
    cassandra-2   1/1     Running   0          8d

Comprueba los nodos de trabajo. Si uno de ellos tiene el estado NotReady, significa que ese nodo ha fallado:

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

Resolución

Elimina el pod de Cassandra inactivo del clúster.

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

Elimina VolumeClaim del nodo inactivo para evitar que el pod de Cassandra intente activarse en el nodo inactivo debido a la afinidad:
```
kubectl get pvc -n your_namespace
kubectl delete pvc volumeClaim_name -n your_namespace
```

Actualiza la plantilla de volumen y crea un PersistentVolume para el nodo que acabas de añadir. A continuación, se muestra una plantilla de volumen de ejemplo:

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

Sustituye los valores por el nuevo nombre de host o IP y aplica la plantilla:
```
kubectl apply -f volume-template.yaml
```

Guía para solucionar problemas de Cassandra Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.

Los pods de Cassandra se quedan en el estado Pendiente

Síntoma

Mensaje de error

Posibles motivos

Diagnóstico

Resolución

Recursos insuficientes

No se ha creado el volumen persistente

Los pods de Cassandra se quedan en el estado CrashLoopBackoff

Síntoma

Mensaje de error

Posibles motivos

Diagnóstico

Resolución

El centro de datos es diferente del anterior

No se ha encontrado el directorio del almacén de confianza

Fallo de nodo

Síntoma

Diagnóstico

Resolución

Guía para solucionar problemas de Cassandra