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 atascados 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-default-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-default-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:

  1. Lista los PVCs del clúster: 
    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. Describe el PVC del pod que está fallando. Por ejemplo, el siguiente comando describe el PVC enlazado 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

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

Diagnóstico

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

  1. Lista los pods para obtener el ID del pod de Cassandra que está fallando: 
    kubectl get pods -n namespace
  2. 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-default-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

  1. Determina qué pods de Cassandra no se están ejecutando: 
    $ 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. 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

  1. Elimina el pod de Cassandra inactivo del clúster. 
    $ kubectl exec -it apigee-cassandra-default-0 -- nodetool status
$ kubectl exec -it apigee-cassandra-default-0 -- nodetool removenode deadnode_hostID
  2. 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
  3. 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"]
  4. Sustituye los valores por el nuevo nombre de host o IP y aplica la plantilla: 
    kubectl apply -f volume-template.yaml

Crear un contenedor de cliente para depuración

En esta sección se explica cómo crear un contenedor de cliente desde el que puedes acceder a las utilidades de depuración de Cassandra como cqlsh. Estas utilidades te permiten consultar tablas de Cassandra y pueden ser útiles para depurar.

Crear el contenedor de cliente

Para crear el contenedor de cliente, siga estos pasos:

  1. El contenedor usa el certificado TLS del pod apigee-cassandra-user-setup. El primer paso es obtener el nombre de este certificado: 
    kubectl get secrets -n apigee |grep "kubernetes.io/tls"|grep apigee-cassandra-user-setup|awk '{print $1}'

    Este comando devuelve el nombre del certificado. Por ejemplo: apigee-cassandra-user-setup-rg-hybrid-b7d3b9c-tls.

  2. A continuación, obtén el nombre del secreto de Datastore: 
    kubectl get secrets -n apigee | grep "datastore.*-creds" | awk '{print $1}'
  3. Abre un archivo nuevo y pega la siguiente especificación de pod en él: 
    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
  4. Guarda el archivo con la extensión .yaml. Por ejemplo: my-spec.yaml.
  5. Aplica la especificación a tu clúster: 
    kubectl apply -f your-spec-file.yaml -n apigee
  6. Inicia sesión en el contenedor: 
    kubectl exec -n apigee cassandra-client -it -- bash
  7. Conéctate a la interfaz cqlsh de Cassandra con el siguiente comando. Introduce el comando exactamente como se muestra: 
    cqlsh ${CASSANDRA_SEEDS} -u ${APIGEE_DML_USER} -p ${APIGEE_DML_PASSWORD} --ssl

Eliminar el pod del cliente

Usa este comando para eliminar el pod del cliente de Cassandra: 

kubectl delete pods -n apigee cassandra-client

Recursos adicionales

Consulta la introducción a los manuales de Apigee y Apigee Hybrid.