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-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.
Falta el controlador de CSI de Amazon EBS El controlador de CSI de Amazon EBS necesario no está instalado.

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

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

Falta el controlador de CSI de Amazon EBS

Si la instancia híbrida se ejecuta en un clúster de EKS, asegúrate de que el clúster de EKS utilice el controlador de interfaz de almacenamiento de contenedores (CSI) de Amazon EBS. Consulta las preguntas frecuentes sobre la migración de Amazon EBS CSI para obtener más información.

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

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 --field-selector type=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. 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.8.8"
    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. Guarda el archivo con la extensión .yaml. Por ejemplo: my-spec.yaml.
  4. Aplica la especificación a tu clúster: 
    kubectl apply -f your-spec-file.yaml -n apigee
  5. Inicia sesión en el contenedor: 
    kubectl exec -n apigee cassandra-client -it -- bash
  6. 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.