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:

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

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

   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.

Controlador CSI do Amazon EBS em falta

Se a instância híbrida estiver a ser executada num cluster do EKS, certifique-se de que o cluster do EKS está a usar o controlador da interface de armazenamento de contentores (CSI) do Amazon EBS. Consulte as Perguntas frequentes sobre a migração do CSI do Amazon EBS para ver detalhes.

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:

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

Crie um contentor de cliente para depuração

Esta secção explica como criar um contentor de cliente a partir do qual pode aceder às utilidades de depuração do Cassandra como cqlsh. Estas utilidades permitem-lhe consultar tabelas do Cassandra e podem ser úteis para fins de depuração.

Crie o contentor de cliente

Para criar o contentor de cliente, siga estes passos:

1. O contentor usa o certificado TLS do pod apigee-cassandra-user-setup O primeiro passo é obter o nome deste certificado:

   kubectl get secrets -n apigee --field-selector type=kubernetes.io/tls | grep apigee-cassandra-user-setup | awk '{print $1}'

   Este comando devolve o nome do certificado. Por exemplo: apigee-cassandra-user-setup-rg-hybrid-b7d3b9c-tls.

2. Abra um novo ficheiro e cole a seguinte especificação do pod no mesmo:

   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. Guarde o ficheiro com a extensão .yaml. Por exemplo: my-spec.yaml.
4. Aplique a especificação ao cluster:

   kubectl apply -f your-spec-file.yaml -n apigee

5. Inicie sessão no contentor:

   kubectl exec -n apigee cassandra-client -it -- bash

6. Estabeleça ligação à interface do Cassandra cqlsh com o seguinte comando. Introduza o comando exatamente como mostrado:

   cqlsh ${CASSANDRA_SEEDS} -u ${APIGEE_DML_USER} -p ${APIGEE_DML_PASSWORD} --ssl

Eliminar o pod do cliente

Use este comando para eliminar o pod do cliente Cassandra:

kubectl delete pods -n apigee cassandra-client

Recursos adicionais

Consulte o artigo Introdução aos manuais de procedimentos do Apigee e do Apigee Hybrid.