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 -n apigee describe pods apigee-cassandra-default-0
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:
- 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 ...
- 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-scnã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.
- Liste os pods para conseguir o ID do pod do Cassandra que está apresentando falhas:
kubectl get pods -n namespace
- 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 pvckubectl -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
- 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
- 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 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
- 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 - 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 - 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": ["ip-10-30-1-36.ec2.internal"]
- 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:
- 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 |grep "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. - Em seguida, busque o nome do segredo do armazenamento de dados:
kubectl get secrets -n apigee | grep "datastore.*-creds" | awk '{print $1}' - 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.5.10" 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: default-datastore-creds # The datastore secret name fetched previously. - name: APIGEE_DML_PASSWORD valueFrom: secretKeyRef: key: dml.password name: default-datastore-creds # The datastore secret name fetched previously. 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 - Salve o arquivo com uma extensão
.yaml. Por exemplo,my-spec.yaml. - Aplique a especificação ao cluster:
kubectl apply -f your-spec-file.yaml -n apigee
- Faça login no contêiner:
kubectl exec -n apigee cassandra-client -it -- bash
- Conecte-se à interface
cqlshdo 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.