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            INTERNAL-IP
gke-hybrid-cluster-apigee-data-178811f1-lv5j      Ready    <none>   34d   v1.21.5-gke.1302   10.138.15.198
gke-hybrid-cluster-apigee-data-d63b8b8d-n41g      NotReady <none>   34d   v1.21.5-gke.1302   10.138.15.200
gke-hybrid-cluster-apigee-data-ec752c0b-b1cr      Ready    <none>   34d   v1.21.5-gke.1302   10.138.15.199
gke-hybrid-cluster-apigee-runtime-ba502ff4-57mq   Ready    <none>   34d   v1.21.5-gke.1302   10.138.15.204
gke-hybrid-cluster-apigee-runtime-ba502ff4-hwkb   Ready    <none>   34d   v1.21.5-gke.1302   10.138.15.203
gke-hybrid-cluster-apigee-runtime-bfa558e0-08vw   Ready    <none>   34d   v1.21.5-gke.1302   10.138.15.201
gke-hybrid-cluster-apigee-runtime-bfa558e0-xvsc   Ready    <none>   34d   v1.21.5-gke.1302   10.138.15.202
gke-hybrid-cluster-apigee-runtime-d12de7df-693w   Ready    <none>   34d   v1.21.5-gke.1302   10.138.15.241
gke-hybrid-cluster-apigee-runtime-d12de7df-fn0w   Ready    <none>   34d   v1.21.5-gke.1302   10.138.15.206

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": ["gke-hybrid-cluster-apigee-data-d63b8b8d-n41g"]
  4. Substitua os valores pelo novo nome de anfitrião/IP e aplique o modelo: 
    kubectl apply -f volume-template.yaml

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.6.9"
    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 seu 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 instruções do Apigee e do Apigee Hybrid.