Guia de resolução de problemas do Cassandra

Este tópico aborda os passos que pode seguir para resolver problemas com o armazenamento de dados do Cassandra. O Cassandra é um repositório de dados persistente que é executado no componente cassandra da arquitetura de tempo de execução híbrida. Consulte também a vista geral da configuração do serviço de tempo de execução.

Os pods do Cassandra estão bloqueados no estado pendente

Sintoma

Ao iniciar, os pods do Cassandra permanecem no estado Pendente.

Mensagem de erro

Quando usa kubectl para ver os estados dos pods, vê que um ou mais pods do Cassandra estão bloqueados no estado Pending. O estado Pending indica que o Kubernetes não consegue agendar o pod num nó: não é possível criar o pod. Por exemplo: 

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

Causas possíveis

Um pod bloqueado no estado Pendente pode ter várias causas. Por exemplo:

Causa Descrição
Recursos insuficientes Não existe CPU ou memória suficiente disponível para criar o pod.
O volume não foi criado O pod está a aguardar a criação do volume persistente.

Diagnóstico

Use kubectl para descrever o grupo de anúncios para determinar a origem do erro. Por exemplo:

kubectl -n namespace describe pods pod_name

Por exemplo: 

kubectl -n apigee describe pods apigee-cassandra-default-0

O resultado pode mostrar um destes possíveis problemas:

  • Se o problema for a falta de recursos, é apresentada uma mensagem de aviso que indica CPU ou memória insuficientes.
  • Se a mensagem de erro indicar que o pod tem PersistentVolumeClaims (PVC) imediatos não associados, significa que o pod não consegue criar o respetivo volume persistente.

Resolução

Recursos insuficientes

Modifique o node pool do Cassandra para que tenha recursos de CPU e memória suficientes. Consulte o artigo Redimensionar um conjunto de nós para ver detalhes.

Volume persistente não criado

Se determinar um problema de volume persistente, descreva o PersistentVolumeClaim (PVC) para determinar por que motivo não está a ser criado:

  1. Liste os PVCs no 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
...
  2. Descreva o PVC do pod com falhas. Por exemplo, o seguinte comando descreve o PVC associado ao 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

    Tenha em atenção que, neste exemplo, a StorageClass denominada apigee-sc não existe. Para resolver este problema, crie a StorageClass em falta no cluster, conforme explicado em Alterar a StorageClass predefinida.

Veja também Depurar pods.

Os pods do Cassandra estão bloqueados no estado CrashLoopBackoff

Sintoma

No arranque, os pods do Cassandra permanecem no estado CrashLoopBackoff.

Mensagem de erro

Quando usa kubectl para ver os estados dos pods, vê que um ou mais pods do Cassandra estão no estado CrashLoopBackoff. Este estado indica que o Kubernetes não consegue criar o pod. Por exemplo: 

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

Causas possíveis

Um pod preso no estado CrashLoopBackoff pode ter várias causas. Por exemplo:

Causa Descrição
O centro de dados difere do centro de dados anterior Este erro indica que o pod do Cassandra tem um volume persistente com dados de um cluster anterior e que os novos pods não conseguem juntar-se ao cluster antigo. Normalmente, isto acontece quando os volumes persistentes desatualizados persistem do cluster do Cassandra anterior no mesmo nó do Kubernetes. Este problema pode ocorrer se eliminar e recriar o Cassandra no cluster.
Diretório Truststore não encontrado Este erro indica que o pod do Cassandra não consegue criar uma ligação TLS. Normalmente, isto acontece quando as chaves e os certificados facultados são inválidos, estão em falta ou têm outros problemas.

Diagnóstico

Verifique o registo de erros do Cassandra para determinar a causa do problema.

  1. Liste os pods para obter o ID do pod do Cassandra com falhas: 
    kubectl get pods -n namespace
  2. Verifique o registo do pod com falhas: 
    kubectl logs pod_id -n namespace

Resolução

Procure os seguintes indícios no registo do pod:

O centro de dados difere do centro de dados anterior

Se vir esta mensagem de registo: 

Cannot start node if snitch's data center (us-east1) differs from previous data center
  • Verifique se existem PVCs desatualizados ou antigos no cluster e elimine-os.
  • Se esta for uma instalação recente, elimine todos os PVCs e tente novamente a configuração. Por exemplo: 
    kubectl -n namespace get pvc
kubectl -n namespace delete pvc cassandra-data-apigee-cassandra-default-0

Diretório Truststore não encontrado

Se vir esta mensagem de registo: 

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

Verifique se a chave e os certificados, se fornecidos no ficheiro de substituições, estão corretos e são válidos. Por exemplo: 

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

Falha do nó

Sintoma

Ao iniciar, os pods do Cassandra permanecem no estado Pendente. Este problema pode indicar uma falha subjacente do nó.

Diagnóstico

  1. Determine que pods do Cassandra não estão em execução: 
    $ 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. Verifique os nós de trabalho. Se um estiver no estado NotReady, significa que esse é o nó que falhou: 
    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

Resolução

  1. Remova o pod Cassandra inativo do cluster. 
    $ kubectl exec -it apigee-cassandra-default-0 -- nodetool status
$ kubectl exec -it apigee-cassandra-default-0 -- nodetool removenode deadnode_hostID
  2. Remova o VolumeClaim do nó inativo para impedir que o pod do Cassandra tente ser iniciado no nó inativo devido à afinidade: 
    kubectl get pvc -n your_namespace
kubectl delete pvc volumeClaim_name -n your_namespace
  3. Atualize o modelo de volume e crie o PersistentVolume para o nó adicionado recentemente. Segue-se um exemplo de um modelo de 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"]
  4. Substitua os valores pelo novo nome de anfitrião/IP e aplique o modelo: 
    kubectl apply -f volume-template.yaml