Cassandra troubleshooting guide

Cassandra pods are stuck in the Pending state

Symptom

When starting up, the Cassandra pods remain in the Pending state.

Error message

When you use kubectl to view the pod states, you see that one or more Cassandra pods are in the Pending state. The Pending state indicates that Kubernetes is unable to schedule the pod on a node: the pod cannot be created. For example:

kubectl get pods -n apigee

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

Possible causes

A pod stuck in the Pending state can have multiple causes. For example:

Cause Description
Insufficient resources There is not enough CPU or memory available to create the pod.
Volume not created The pod is waiting for the persistent volume to be created.

Diagnosis

Use kubectl to describe the pod to determine the source of the error. For example:

kubectl -n apigee describe pods apigee-cassandra-0

The output may show one of these possible problems:

  • If the problem is insufficient resources, you will see a Warning message that indicates insufficent CPU or memory.
  • If the error message indicates that the pod has unbound immediate PersistentVolumeClaims (PVC), it means the pod is not able to create its Persistent volume.

Resolution

Insufficient resources

Modify the Cassandra node pool so that it has sufficient CPU and memory resources. See Resizing a node pool for details.

Persistent volume not created

If you determine a persistent volume issue, describe the PersistentVolumeClaim (PVC) to determine why it is not being created:

  1. List the PVCs in the cluster:
    kubectl -n apigee 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
    ...
  2. Describe the PVC for the pod that is failing. For example, if PVC cassandra-data-apigee-cassandra-0 belongs to a pod in the Pending state, use this command to describe the PVC:
    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

    Note that in this example, the StorageClass named apigee-sc does not exist. To resolve this problem, create the missing StorageClass in the cluster, as explained in Change the default StorageClass.

  3. See also Debugging Pods.

    Cassandra pods are stuck in the CrashLoopBackoff state

    Error message

    When you use kubectl to view the pod states, you see that one or more Cassandra pods are in the CrashLoopBackoff state. This state indicates that Kubernetes is unable to create the pod. For example:

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

    Symptom

    When starting up, the Cassandra pods remain in the CrashLoopBackoff state.

    Possible causes

    A pod stuck in the CrashLoopBackoff state can have multiple causes. For example:

    Cause Description
    Data center differs from previous data center This error indicates that the Cassandra pod has a persistent volume that has data from a previous cluster, and the new pods are not able to join the old cluster. This usually happens when stale persistent volumes persist from the previous Cassandra cluster on the same Kubernetes node. This problem can occur if you delete and recreate Cassandra in the cluster.
    Truststore directory not found This error indicates that the Cassandra pod is not able to create a TLS connection. This usually happens when the provided keys and certificates are invalid, missing, or have other issues.

    Diagnosis

    Check the Cassandra error log to determine the cause of the problem.

    1. List the pods to get the ID of the Cassandra pod that is failing:
      kubectl get pods -n apigee
    2. Check the failing pod's log:
      kubectl logs pod_id -n apigee

    Resolution

    Data center differs from previous data center

    Cannot start node if snitch's data center (us-east1) differs from previous data center”
    • Check if there are any stale or old PVC in the cluster and delete them.
    • If this is a fresh install, delete all the PVCs and re-try the setup. For example:
      kubectl -n apigee get pvc
        kubectl -n apigee delete pvc cassandra-data-apigee-cassandra-0

    Truststore directory not found

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

    Verify the key and certificates if provided in your overrides file are correct and valid. For example:

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