Guia de solução de problemas do Cassandra

Você está visualizando a versão 1.7 da documentação da Apigee híbrida. This version is end of life. You should upgrade to a newer version. Para mais informações, consulte Versões compatíveis.

Version 1.7 (unsupported)

Versões com suporte:

• v1.12 (mais recente)
• v1.11
• v1.10
• Lista de versões com suporte

Versões sem suporte:

• v1.9
• v1.8
• v1.7
• v1.6
• v1.5
• v1.4
• v1.3
• v1.2
• v1.1

Neste tópico, você verá etapas para resolver e corrigir problemas com o armazenamento de dados do Cassandra. O Cassandra é um armazenamento de dados persistente executado no componente cassandra da arquitetura de ambiente de execução híbrida. Consulte também Visão geral da configuração do serviço de ambiente de execução.

Os pods do Cassandra estão presos no estado pendente

Sintoma

Ao serem iniciados, os pods do Cassandra permanecem no estado Pendente.

Mensagem de erro

Ao usar kubectl para visualizar os estados do pod, você verá que um ou mais pods do Cassandra estão parados no estado Pending. O estado Pending indica que o Kubernetes não pode agendar o pod em um nó: o pod não pode ser criado. 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 preso no estado pendente pode ter várias causas. Exemplo:

Causa	Descrição
Recursos insuficientes	Não há CPU ou memória suficiente disponível para criar o pod.
Volume não criado	O pod aguarda a criação do volume permanente para ser criado.

Diagnóstico

Use kubectl para descrever o pod a fim de determinar a origem do erro. Exemplo:

kubectl -n namespace describe pods pod_name

Exemplo:

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

A saída pode mostrar um dos seguintes problemas:

• Se o problema for recursos insuficientes, você verá uma mensagem de aviso que indica CPU ou memória insuficientes.
• Se a mensagem de erro indicar que o pod tem PersistentVolumeClaims (PVC) imediatos desvinculados, isso significa que o pod não pode criar o volume permanente dele.

Resolução

Recursos insuficientes

Modifique o pool de nós do Cassandra para que tenha recursos de CPU e memória suficientes. Consulte Como redimensionar um pool de nós para detalhes.

Volume permanente não criado

Se você determinar um problema de volume permanente, descreva o PersistentVolumeClaim (PVC) para determinar por que ele não está sendo 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 para o pod que está falhando. Por exemplo, o comando a seguir descreve o PVC vinculado 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

   Neste exemplo, o StorageClass chamado apigee-sc não existe. Para resolver esse problema, crie o StorageClass ausente no cluster, conforme explicado em Alterar o StorageClass padrão.

Consulte também Como depurar pods.

Os pods do Cassandra estão presos no estado CrashLoopBackoff

Sintoma

Durante a inicialização, os pods do Cassandra permanecem no estado CrashLoopBackoff.

Mensagem de erro

Ao usar kubectl para visualizar os estados do pod, você verá que um ou mais pods do Cassandra estão no estado CrashLoopBackoff. Esse estado indica que o Kubernetes não pode criar o pod. 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 parado no estado CrashLoopBackoff pode ter várias causas. Exemplo:

Causa	Descrição
O data center é diferente do data center anterior.	Esse erro indica que o pod do Cassandra tem um volume permanente que tem dados de um cluster anterior e os novos pods não podem unir o cluster antigo. Isso geralmente acontece quando os volumes permanentes desatualizados persistem do cluster do Cassandra anterior no mesmo nó do Kubernetes. Esse problema pode ocorrer se você excluir e recriar o Cassandra no cluster.
Diretório Truststore não encontrado	Esse erro indica que o pod do Cassandra não consegue criar uma conexão TLS. Isso geralmente acontece quando as chaves e os certificados fornecidos são inválidos, ausentes ou têm outros problemas.

Diagnóstico

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

1. Liste os pods para conseguir o ID do pod do Cassandra que está apresentando falhas:

   kubectl get pods -n namespace

2. Verifique o registro do pod com falha:

   kubectl logs pod_id -n namespace

Resolução

Procure as seguintes dicas no registro do pod:

O data center é diferente do data center anterior.

Se você vir esta mensagem de registro:

Cannot start node if snitch's data center (us-east1) differs from previous data center

• Verifique se há PVC desatualizado ou antigo no cluster e exclua-os.
• Se for uma nova instalação, exclua todos os PVCs e tente novamente. Exemplo:

  kubectl -n namespace get pvc
  kubectl -n namespace delete pvc cassandra-data-apigee-cassandra-default-0

Diretório Truststore não encontrado

Se você vir esta mensagem de registro:

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

Verifique a chave e os certificados se os fornecidos no seu arquivo de substituição estão corretos e válidos. Por exemplo:

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

Falha no nó

Sintoma

Ao serem iniciados, os pods do Cassandra permanecem no estado "Pendente". Esse problema pode indicar uma falha de nó subjacente.

Diagnóstico

1. Determine quais 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, será o nó com falha:

   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 do 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 aparecer no nó inativo por causa da afinidade:

   kubectl get pvc -n your_namespace
   kubectl delete pvc volumeClaim_name -n your_namespace

3. Atualize o modelo de volume e crie PersistentVolume para o nó recém-adicionado. Veja a seguir um exemplo de 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 do host/IP e aplique o modelo:

   kubectl apply -f volume-template.yaml

Criar um contêiner do cliente para depuração

Nesta seção, explicamos como criar um contêiner do cliente em que é possível acessar utilitários de depuração do Cassandra, como cqlsh. Esses utilitários permitem consultar tabelas do Cassandra e podem ser úteis para fins de depuração.

Criar o contêiner do cliente

Para criar o contêiner do cliente, siga estas etapas:

1. O contêiner usa o certificado TLS do pod apigee-cassandra-user-setup. A primeira etapa é buscar esse nome de certificado:

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

   Esse comando retorna o nome do certificado. Por exemplo, apigee-cassandra-user-setup-rg-hybrid-b7d3b9c-tls.

2. Abra um novo arquivo e cole a seguinte especificação de pod nele:

   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.7.6"
       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. Salve o arquivo com uma 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. Faça login no contêiner:

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

6. Conecte-se à interface cqlsh do Cassandra com o comando a seguir. Digite o comando exatamente como mostrado:

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

Como excluir o pod cliente

Use este comando para excluir o pod de cliente do Cassandra:

kubectl delete pods -n apigee cassandra-client

Outros recursos

Consulte Introdução aos playbooks da Apigee e da Apigee híbrida.